Subject: [MMUSIC] comments on draft-ietf-mmusic-sctp-sdp-00

From: "Dan Wing" <[email-masked]>
Date: Thu, 4 Aug 2011 14:01:49 -0700

A couple of comments when I was reviewing draft-ietf-mmusic-sctp-sdp-00:

Background: SCTP allows sending multiple streams through a single 
connection (that is, over a single 5-tuple of source port, destination
port, protocol=SCTP, source IP, destination IP).  By using a single 
connection, there is one congestion control context for all of 
the streams within that connection.  

Question:  I notice that draft-ietf-mmusic-sctp-sdp doesn't try
to take advantage of that SCTP capability.  I admit it would be
pretty complex considering how SDP (and TCP and UDP) are all very
much tied to the concept of using ports to demultiplex traffic.
However, with the work going on in RTCWEB (which wants to multiplex
audio and vidoe over the same 5 tuple), should we consider how
SCTP can signal this functionality in SDP?

Small issue related to NAT:

   SCTP specific features (not present in UDP/TCP), such as the checksum
   (CRC32c) value calculated on the whole packet (not just the header)
   or its multihoming capabilities, present new challenges for NAT
   traversal.  [I-D.ietf-behave-sctpnat] describes an SCTP specific
   variant of NAT, which provides similar features of Network Address
   and Port Translation (NAPT).

To work with draft-ietf-behave-sctpnat, the client and the server SCTP 
implementations also need to support and use the DISABLE_RESTART extension 
described in draft-ietf-tsvwg-natsupp.  I suggest adding SHOULD
implement draft-ietf-tsvwg-natsupp.

-d

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 8 Aug 2011 11:12:41 +0300

Hi Dan,

thanks for your comments. Answers inline:

> the streams within that connection.  

correct, although in SCTP terminology that is called an association
(instead of a connection).

> SCTP can signal this functionality in SDP?

Yes, taking advantage of the multi-stream capability of SCTP for
something else than HOLB avoidance would be useful indeed. I believe the
way to use streams by a particular application or set of applications
(e.g., RTCWeb) needs to be done separately. That is, in my view, this
draft provides general guidelines to describe SCTP associations in SDP.
If a particular application wants to do something more special, such as
multiplexing different types of traffic in different streams, they would
specify that separately.

> implement draft-ietf-tsvwg-natsupp.

Yes, I agree SCTP endpoints should try and support that. The question is
whether this is the right document to specify that. This document only
applies to SCTP associations that are established using SDP (i.e.,
offer/answer) while the recommendation to use natsupp would be a general
recommendation, which would also be applicable to SCTP associations
established in the traditional way (i.e., no SDP involved). So, to me,
this sounds more like something to be documented as best current
practice for SCTP.

With respect to the feedback we got in Quebec, I agree that adding use
cases to the draft would be useful.

Thanks,

Gonzalo