Subject: [tsvwg] Fwd: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03

From: James Polk <[email-masked]>
Date: Wed, 20 Mar 2013 13:53:27 -0500

<chair hat on>

this review by Magnus might be of interest to some in this WG.

please comment on the MMUSIC list though, for 
those WG chair's to be aware of your support/comments, concerns, or whatever...

James

>Date: Wed, 20 Mar 2013 16:11:38 +0100
>From: Magnus Westerlund <[email-masked]>
>To: "mmusic (E-mail)" <[email-masked]>,
>         <[email-masked]>
>Subject: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03
>
>
>Hi,
>
>I have reviewed the SDP description of SCTP and have some comments and
>suggestions.
>
>1. My first comments is a very general one and concerns the relationship
>between the proposed SCTP related proto identifiers and ICE for the
>DTLS/SCTP encapsulation.
>
>When ICE was defined it was natural to include ICE by reftorfitting it
>to existing proto identifiers. However, given that this specification
>intorduce a number of new identifiers I do woner if we should be more
>explicit about the ICE usage in the proto field. I think have both pro
>and cons for this.
>
>So my considerations is basically to include specification of
>ICE/DTLS/SCTP, where the lower layer transport is defined by what ICE
>agrees on. This makes a lot of sense given that ICE can in fact arrive
>on the usage of TCP/framing/DTLS/SCTP, TCP/TURN/DTLS/SCTP in addition to
>more expected choices as UDP/DTLS/SCTP. This makes it clears that you do
>require ICE to negotiate this transport flow. At the same time it is a
>significant downside if ones negotiation needs are to chose between
>using ICE or a specific lower layer transport.
>
>These comments doesn't apply when one runs SCTP on top of IP.
>
>2. Section 1:
>RFC4145 [RFC4145] specifies a general mechanism for
>    describing and establishing TCP (Transmission Control Protocol)
>    streams.
>
>I do dislike that usage of the RFC number as the explanation of what the
>referenced document is. The previous sentence is how I prefer it to be
>done:
>    SDP (Session Description Protocol) [RFC4566] provides a general-
>    purpose format for describing multimedia sessions in announcements or
>    invitations.
>
>Use the document title or an abbreviated explanation for what the
>referenced document specifies and one gets much better flow in the
>reading as one don't have stop look up the reference to find out what is
>referred to.
>
>3. Section 1:
>I think having first a paragraph for SCTP and then having "Additionaly
>.." with the other two protos are bit strange. Why not simpley say. This
>document defines three proto identifiers: list of them with explnation.
>
>4. Section 1:
>    DTLS/SCTP :  to allow the usage of SCTP on top of the Datagram
>       Transport Layer Security (DTLS) protocol, as defined in
>       [I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP.  SCTP over DTLS is
>       used by the RTCWeb protocol suite for transporting non- media data
>       between browsers.
>
>This definitions says nothing of the lower transport layer for DTLS/SCTP
>even if UDP is referred to in a later section. I think this needs to be
>clarified and discussed in the context of which lower layers do we
>expect to be supported? From my perspective I think two makes sense.
>ICE/DTLS/SCTP that allows ICE to negoiate what ever and then
>UDP/DTSL/SCTP that only uses UDP as lower layer. Lets other add other
>variants in the future if needed.
>
>5. Section 3:
>    The 'DTLS/SCTP' protocol identifier indicates that the media
>    described will use SCTP on top of the Datagram Transport Layer
>    Security (DTLS) protocol as specified in
>    [I-D.tuexen-tsvwg-sctp-dtls-encaps].
>
>I would like to point out that the referenced document does not at all
>indicate what lower layer is being used under DTLS.
>
>6. Section 4.1:
>
>This section discuss the usage of the "data channels" within the SCTP
>association. My personal position is that for the moment this appears to
>be unnecessary. The most important part is the SCTP association
>establishment. Then one can discuss the general application using the
>SCTP association as whole. Examples of such are WebRTC data channel.
>
>If anyone want stream level information in SDP then I propose that this
>is handled as a extension to this signaling, not an from the start
>included functionality as we don't appear to have clear requirement for
>that.
>
>7. Section 4.2:
>
>What are the requirements behind being able to establish multiple SCTP
>association over the same DTLS connection? I am very unclear why this
>would be required, and if not really needed I would suggest keeping
>things simple.
>
>8. Section 4.3: I guess this can for the moment be removed as it appears
>to be taken care in other places, such as the RTCWEB WG data channel
>protocol proposal.
>
>9. If you are removing the multiple association and the "data channel"
>parameters then most of the issues in section 5 vanish. If not I have
>additional feedback on this section.
>
>10. Section 8.
>
>    Current NATs do not typically support SCTP.  As an alternative to
>    design SCTP specific NATs, Encapsulating SCTP into UDP
>    [I-D.tuexen-sctp-udp-encaps] makes it possible to use SCTP in
>    networks with legacy NAT and firewalls not supporting SCTP.
>
>First of all, there is a WG version for this document:
>draft-ietf-tsvwg-sctp-udp-encaps-14. Which is in IESG evaluation. Thus I
>wonder why signalling for this is not included when all the other
>options are included, even less mature ones then this?
>
>To me it looks like this document need to have some high level decisions
>on what to include and not and then try to finish it up within the
>agreed constraints. From my perspective I think it should focus on a
>single SCTP association per m= line and the actual SCTP association.
>
>Cheers
>
>Magnus Westerlund
>
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVM
>----------------------------------------------------------------------
>Ericsson AB                | Phone  +46 10 7148287
>Färögatan 6                | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden| mailto: [email-masked]
>----------------------------------------------------------------------
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic