IETF Logo Mail Archive

Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-02

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 18 December 2015 22:24 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41711B3983 for <mmusic@ietfa.amsl.com>; Fri, 18 Dec 2015 14:24:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-CsI2f-ITeN for <mmusic@ietfa.amsl.com>; Fri, 18 Dec 2015 14:24:21 -0800 (PST)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680FF1B3987 for <mmusic@ietf.org>; Fri, 18 Dec 2015 14:24:21 -0800 (PST)
Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-01v.sys.comcast.net with comcast id vAQ11r0022Qkjl901AQLzp; Fri, 18 Dec 2015 22:24:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-15v.sys.comcast.net with comcast id vAQL1r0013KdFy101AQLtT; Fri, 18 Dec 2015 22:24:20 +0000
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B37C8B1E5@ESESSMB209.ericsson.se> <CABkgnnVUy+FiRps1KWAkmhbTvS0UsYy70t4XRmWWE9x1Gp11Cw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37CED885@ESESSMB209.ericsson.se> <CAD5OKxvw7Hox2HvDxH=Sq5s4oCMUH1MWApNSf+FXTWVyoFFjoA@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56748793.2080805@alum.mit.edu>
Date: Fri, 18 Dec 2015 17:24:19 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <CAD5OKxvw7Hox2HvDxH=Sq5s4oCMUH1MWApNSf+FXTWVyoFFjoA@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450477460; bh=nEWhN47pXwk5kuellKitQckpeLHEWsv8kMHfrFiqXUI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=dt9Uhf5sul7Tp/q8OrsVa+scC0Cq++FyAD8BXfdIoxt+IEB3E/wFOj852RDmX8a7w XHhgZfnrU3uSMRyxFnxbeaw3/DmE+1ut4PPNEnvI5f0d+dThrAYUng5hszjDSXuG3V fbQnY0gOS0hQkGBvXyE0ZalF/5dz6z8vnz5iaXTBNDaHz5nHIgqTa8wHjhz5qaqdkZ ggP9Zjfec4dbdp583MvyKgq1zk4xu7qbxnDMv3jdErZILV3Nt1pwLkuBM1l/nUtTKB FPcDWYxOAokbSOLQSDEMreFEnJyKD2ZgOU3uKp+pCepUdpS6L2KSfPyF/M/7jDbLHT 5PBNNODBd20kg==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/srmMkPOs-M3IoBWMr504iNnX4Cc>
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-02
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2015 22:24:22 -0000

On 12/18/15 2:31 PM, Roman Shpount wrote:
> Hi Martin,
>
> Thanks again for your comments!
>
> The whole reason for section 8.1 was DTLS over SCTP (RFC 6083).

Is there any reason for DTLS over SCTP? Is there any case where it is 
preferable to SCTP over DTLS?

	Thanks,
	Paul

> This RFC makes several unfortunate design decisions which make it
> incompatible with dtls-sdp.
>
> In particular RFC 6083 states:
>
> 1. DTLS procedures for retransmissions MUST NOT be used
> (https://tools.ietf.org/html/rfc6083#section-3.5)
>
> 2. Each DTLS connection MUST be established and terminated within
> the same SCTP association (https://tools.ietf.org/html/rfc6083#section-4.2)
>
> 3. RFC 6083 describes setting up and shutting down multiple DTLS
> associations (which it insists on calling connections) over the same
> SCTP association.
>
> I am not sure what was the use case for RFC 6083 and if it is being used
> anywhere, so I am not sure if we can update it.
>
> Due to RFC 6083 we had to do the following provisions:
>
> 1. Since retransmissions is disabled at DTLS level and since all DTLS
> associations must be established over the same SCTP association, we
> cannot seamlessly switch the protocol under DTLS from SCTP to UDP. This
> conflicts with our usage of dtls-connection=existing attribute. Also, if
> anybody ever defines SCTP ICE candidate type, this will make it
> impossible to switch between the candidates of different types. For now,
> we decided to prohibit switching from reliable (SCTP) to unreliable (UDP
> or UDP over TCP  in RFC 4571 framing). UDP over TCP in RFC 4571 framing
> is considered unreliable since such connections are often not
> end-to-end, and most importantly, DTLS retransmissions is not disabled,
> so switching between UDP and UDP over TCP with RFC4571 framing is allowed.
>
> 2. Since RFC 6083 specifies how multiple DTLS association can share the
> same SCTP based transport, we need to make a special allowance which
> defines when two DTLS associations can run over the same transport. This
> is the reason for section 8.1
>
> Another option would be to specify that RFC 6083 are not compatible with
> dtls-sdp and get rid of the complications caused by this transport.
>
> Regards,
> _____________
> Roman Shpount
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

v2.23.0 | Report a Bug | By Email