Re: [MMUSIC] SCTP question: Where does it multiplex?

"Dan Wing" <dwing@cisco.com> Tue, 11 December 2012 19:25 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBAB21F8482 for <mmusic@ietfa.amsl.com>; Tue, 11 Dec 2012 11:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.434
X-Spam-Level:
X-Spam-Status: No, score=-110.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nfPeALOo3Eu for <mmusic@ietfa.amsl.com>; Tue, 11 Dec 2012 11:25:34 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7A99821F847C for <mmusic@ietf.org>; Tue, 11 Dec 2012 11:25:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6898; q=dns/txt; s=iport; t=1355253934; x=1356463534; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=PiphU//hkfEvvCOgUq+4i03W3BXSVSQgwjpNtmYqYd8=; b=Z3K7DsuuL19zETdokzRfX58S1xsaTBXfOMsrTocHBcIiVOon/Vx3fbVf uXiKoRDDWmbjYSJDC8q4g5Rt9w7xk3w2P/2pB/xaPlkmykhvpfxnBlUye W1+k23JgHfpKgvFsU9no3h6ZZCt//GK8aIznEPUtVcv1mcqJVf7lIKlYd g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApQHAJyHx1CrRDoG/2dsb2JhbABEDoM6uwYWc4IeAQEBAwEIAjAtBAMEBwUHAQMCCQ4DBAEBAScHGS0JCAIEEwsFh3sFqymQVYxKFYQuA4hghRyIC5BIgjVfgUM
X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="66297998"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 11 Dec 2012 19:25:31 +0000
Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBBJPVnc009578; Tue, 11 Dec 2012 19:25:31 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Paul Kyzivat' <pkyzivat@alum.mit.edu>
References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu> <010401cdd7d0$d006d310$70147930$@cisco.com> <50C786C8.2010403@alum.mit.edu>
In-Reply-To: <50C786C8.2010403@alum.mit.edu>
Date: Tue, 11 Dec 2012 11:25:31 -0800
Message-ID: <023f01cdd7d5$48e33c70$daa9b550$@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGlNUoiDi8ItBUA8zunPWFLx+5pWALXFbmGAbkvJqYBA93guALjhCBmATyC1jQB06oIXAHHwb56l/rBTqA=
Content-Language: en-us
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 11 Dec 2012 19:25:35 -0000

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: Tuesday, December 11, 2012 11:17 AM
> To: Dan Wing
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
> 
> Hi Dan,
> 
> Comments inline
> 
> On 12/11/12 1:53 PM, Dan Wing wrote:
> >> -----Original Message-----
> >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> >> Behalf Of Paul Kyzivat
> >> Sent: Tuesday, December 11, 2012 7:43 AM
> >> To: mmusic@ietf.org
> >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
> >>
> >> More inline.
> >>
> >> On 12/11/12 4:08 AM, Salvatore Loreto wrote:
> >>> Hi Paul,
> >>>
> >>> see in line!
> >>>
> >>> On 12/3/12 10:00 PM, Paul Kyzivat wrote:
> >>>> Commenting on a different point
> >>>>
> >>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote:
> >>>>
> >>>>> The interesting difference is that the multiplexing between
> >>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP
> >>>>> traffic is not carried in SSRCs, which means:
> >>>>>
> >>>>> - There can be only one DTLS/SCTP stream in a bundle (which may
> >>>>> have multiple associations, as you state below); you can't have
> >>>>> multiple lines with proto DTLS/SCTP in a bundle.
> >>>>
> >>>> I am not an SCTP expert. But IIUC, SCTP was designed to run
> >>>> directly over IP. It has its own notion of port used to demux
> >>>> multiple SCTP associations over the same IP address.
> >>>>
> >>>> I presume that that same mechanism is still there when SCTP is run
> >>>> over DTLS over UDP.
> >>>>
> >>>> So, the traffic coming over DTLS must first be demuxed into RTP
> >>>> traffic and SCTP traffic.
> >>> based on the current stack the SCTP traffic is the only traffic that
> >>> runs directly over the DTLS stack.
> >>
> >> Yes, that is what I thought. But Harald has been asking about
> >> multiplexing this with RTP traffic. (Actually I think it would be
> >> DTLS/SRTP traffic that it would be multiplexed with.)
> >>
> >>> What I am trying to do is to include the Randell Jesup (I am
> >>> including him in CC as I am not sure he is subscribed to this
> mailing list)
> >>>    suggestion to give the possibility to have multiple SCTP
> >>> *associations* running  on top of the same DTLS session and of
> >>> course providing a way to signal it in SDP.
> >>
> >> IIUC, SCTP (having been designed as a transport layer protocol)
> >> defines its own notion of port, and has fields in its protocol to
> >> carry the local and remote port number. Presumably those fields are
> >> still there when run over UDP or DTLS. So it should be possible to
> >> support multiple SCTP associations over the same DTLS connection,
> >> each distinguished by its own port pair.
> >
> > Yes, SCTP has its own notion of ports.  How this works when SCTP is
> > carried over UDP is not quite clear, especially because SCTP assumes a
> > NAPT will not rewrite the SCTP port number (SCTP endeavors to make
> > such port rewriting difficult).  But of course a NAPT (and the MAP
> > techniques) rewrite UDP port numbers.  I believe SCTP would only be
> > able to successfully convey its UDP port numbers for a device that is
> > not behind a NAT (that is, a server sitting directly on the Internet,
> > rather than a remote peer that is behind a NAT).  Creative use of PCP,
> > NAT-PMP, or UPnP IGD would improve that situation in the future.
> 
> I find what you say above confusing.

It is confusing, because SCTP's specifications require different
things of a NAPT than UDP, TCP, or DCCP.  Specifically, SCTP's
specifications require the NAPT to not rewrite (not change) the
source port number of outgoing SCTP-over-IP packets.  Reference
draft-ietf-behave-sctpnat.

> SCTP running naked over IP would still have its own ports.
> If that ran over a path with a NAPT, then I could see why the NAPT might
> want to do the same as it does with UDP and TCP, and so replace
> addr/port pairs to minimize addr usage. (That's if the NAPT supported
> SCTP at all - I  gather most don't.)

I am not aware of any shipping NAPT that supports SCTP.


> But with SCTP over DTLS over UDP, there is a UDP port, and then
> presumably a separate SCTP port carried in the SCTP protocol within the
> UDP message.

Right.

And the new SCTP_REMOTE_UDP_ENCAPS_PORT socket option has some 
relationship, but I do not understand how it works.  Reference
draft-ietf-tsvwg-sctp-udp-encaps.

> An NAPT on the path would presumably be messing with the UDP port. Given
> use of DTLS, the NAPT won't even be able to tell that SCTP is being
> used, much less mess with the SCTP port.

Right.

> >> That of course depends on having a signaling mechanism to set it up.
> >
> > After the initial SCTP association is created, SCTP could be allowed
> > to do its own thing (that is, chose to find and use other ports).
> 
> Here you are talking about finding and using other UDP addr/port pairs?

Yes, for mobility.

> That is explicitly excluded in the DTLS/SCTP mapping.

I am thinking about where to layer mobility and multipath for RTP 
(MPRTP) and for SCTP.  Do we do that with MICE 
(draft-wing-mmusic-ice-mobility) or does SCTP do mobility itself?  If
we do it with MICE, we need to disable or prevent SCTP from adding 
/ removing interfaces itself, which is why SCTP includes its own
ability to signal IP addresses and ports in SCTP itself.

-d


> 	Thanks,
> 	Paul
> 
> > SCTP's behavior in this regard is similar to MPRTP (multipath RTP),
> > but of course they are not identical.
> >
> >>> to be clear: at moment WebRTC allows only one SCTP association per
> >>> PC, so this is something that would be nice to define just to be
> >>> ready for the future.
> >>
> >> AFAIK WebRTC is just one possible user of this mechanism. The SDP
> >> mechanism shouldn't be limited by the constraints of WebRTC. It would
> >> be very difficult to define the SDP so that it was impossible to set
> >> up multiple SCTP associations over different 5-tuples.
> >>
> >>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic
> >>>> can be demuxed based on SCTP port. And once the traffic for a
> >>>> single SCTP port is identified, it can be demuxed based on stream
> number.
> >>>>
> >>>> Representing this in SDP is a challenge. Some variant of the bundle
> >>>> proposal might allow bundling together several RTP m-lines and some
> >>>> DTLS/SCTP m-lines. This would require a mechanism for specifying
> >>>> the SCTP port number - already an open issue (#3) in
> >>>> draft-ietf-mmusic-sctp-sdp-02.
> >>> I agree that it is a challange how then to bundle everything
> >>> together
> >>
> >> But it is a challenge that needs to be tackled if we are to realize
> >> Harald's dream.
> >
> > -d
> >
> >
> >