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

"Dan Wing" <dwing@cisco.com> Tue, 11 December 2012 18:53 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 E846E21F85D6 for <mmusic@ietfa.amsl.com>; Tue, 11 Dec 2012 10:53:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.393
X-Spam-Level:
X-Spam-Status: No, score=-110.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 98V3eQPQUadF for <mmusic@ietfa.amsl.com>; Tue, 11 Dec 2012 10:53:32 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 53A9B21F855F for <mmusic@ietf.org>; Tue, 11 Dec 2012 10:53:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4479; q=dns/txt; s=iport; t=1355252012; x=1356461612; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=NIvZ1XRX2KT0JMJaNvIochwjl2PklSWCCBZ1l4A9+v4=; b=TS11urRfT32QQYP/9hOtA/hOS3Jc8X4hQ3pQNBjje6f0rNFRmZns9h8w em6NO428giywfB//370q6V4A+To6u9PieMQB1akJ4ET/H7b8sfsjDhzLm 3NWgsEdLdaVDF5dFLwdRSzCDaWAub0M4+lzgT0nXFbQJtJJBqnRf1y/KX o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwGABaAx1CrRDoG/2dsb2JhbABEDoM6un0Wc4IeAQEBAwEIAjAtBAMQBwEDAgkOAwQBAQEnBxktCQgCBAESCwWHewWrI5BajEoVhC4DiGCFHIgLkEiCNV+BQw
X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="63720055"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 Dec 2012 18:53:31 +0000
Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBBIrUKY020842; Tue, 11 Dec 2012 18:53:30 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Paul Kyzivat' <pkyzivat@alum.mit.edu>, mmusic@ietf.org
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>
In-Reply-To: <50C7548C.3090807@alum.mit.edu>
Date: Tue, 11 Dec 2012 10:53:30 -0800
Message-ID: <010401cdd7d0$d006d310$70147930$@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+5pWALXFbmGAbkvJqYBA93guALjhCBmATyC1jSYF41PAA==
Content-Language: en-us
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 18:53:33 -0000

> -----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.

> 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).

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