Re: [MMUSIC] BUNDLE and DATA CHANNEL and SHIM

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 30 April 2013 16:20 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 9B9D621F9BD4 for <mmusic@ietfa.amsl.com>; Tue, 30 Apr 2013 09:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.403
X-Spam-Level:
X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=0.6, J_CHICKENPOX_19=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyPILz4qaX9t for <mmusic@ietfa.amsl.com>; Tue, 30 Apr 2013 09:20:11 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA8F21F9BB9 for <mmusic@ietf.org>; Tue, 30 Apr 2013 09:20:10 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta09.westchester.pa.mail.comcast.net with comcast id WBqy1l0081ap0As59GL9Rr; Tue, 30 Apr 2013 16:20:09 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id WGL91l0113ZTu2S3iGL9PQ; Tue, 30 Apr 2013 16:20:09 +0000
Message-ID: <517FEF39.2030306@alum.mit.edu>
Date: Tue, 30 Apr 2013 12:20:09 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1C3682C9@ESESSMB209.ericsson.se> <517EA875.1020002@alum.mit.edu> <CABkgnnWOnUZGcHONbf8Mv7kLX0ybwS_tTacU=2kRC0PDUE8m8A@mail.gmail.com> <517ECCFF.6040706@alum.mit.edu> <CABkgnnX9W+4BpJfphwoMniNEvqrMJ3yevydbDhMH8gw8Xa1njA@mail.gmail.com> <517FD8C2.307@ericsson.com>
In-Reply-To: <517FD8C2.307@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367338809; bh=672hbDOl+MogqIQL7L3bRnDC0TlHE5SGa/mh5NQ+GzM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UARAx0D+FYqHkYscpoulc/a3dcyP2cUPPWPMd4hGEdWzNAEx+R1dbaN6yhLGzNMx4 r6sQsdrqXnKzJY1D42JsZEMt2vpynYEoxmbrm0MF6GaDvAbOwN52hV3jllsOEvGhq2 UBPaRLoh//MM/fQMDq1AEYtfgJ/1oe79C74iQES/8avYywpr/6UQ29ZEN/I0AM9n9j 73LCwjHZVpWiQRtHkpWfUXEzZPhOSkWUzc5lHzkesUM2xA8erOZcfujCwP5n57ygHL qTkwHYWsyaowJvzgtu+LGB+mA9V8jPAZb02Bh0PSEP/R6smxB20beHFdB4VSNXSJq0 Lbr1yHs9jTXiQ==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL and SHIM
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, 30 Apr 2013 16:20:28 -0000

Inline...

On 4/30/13 10:44 AM, Magnus Westerlund wrote:
> On 2013-04-30 01:03, Martin Thomson wrote:
>> On 29 April 2013 12:41, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>> One more thing - a question for all:
>>>
>>> Do you agree that there is a need to support more than one way to demux RTP,
>>> and hence a need to signal what way is to be used?
>>>
>>> Or do you think we will be able to reach agreement on a single algorithm, so
>>> that signaling of the algorithm isn't required?
>>
>> There is agreement in avtcore to build two demux schemes.  The need to
>> signal the choice of demux scheme has already been made for us.
>>
>> Yes, we could define BUNDLE to mean "demux by SSRC (and maybe PT (oh
>> and protocol if you've got this DTLS thingy))" and then have a
>> SHIMBUNDLE grouping.  That would be actively antisocial.
>
> Can you please clarify why you think this is anti-social?
>
> I would like to point out that BUNDLE and SHIM operates at different
> levels. To my understanding BUNDLE is a way of using multiple media
> descriptions (m= lines) to describe one RTP session.
>
> SHIM is an explicit layer for transmitting multiple independent RTP
> session on the same lower layer transport. Each RTP session will be
> described using its own signaling, which could include BUNDLE of
> multiple m= lines.

AFAIK the SDP in support of shim has never really been discussed.
The bundle proposal. But the bundle draft does say:

    When media is transported using the Real-Time Protocol (RTP)
    [RFC3550], the default assumption of the mechanism is that all media
    associated with a "BUNDLE" group will form a single RTP Session
    [RFC3550].  However, future specifications can extend the mechanism,
    in order to negotiate RTP Session multiplexing, i.e.  "BUNDLE" groups
    where media associated with a group form multiple RTP Sessions.

which is a hint that it *could* be extended to apply when shim is used.

My thinking is that this bundling stuff is sufficiently messy and 
complex that we won't want to do something similar but different for shim.

Instead, I am inclined to view the shim as just another mechanism for 
multiplexing. If so, then a suitable mechanism for signaling the sort(s) 
of multiplexing to be used in a bundle should support it as well.

> The transmission of DTLS/SCTP over the same UDP flow as an RTP session
> is yet another problem of who shares the lower layer transport.

Yep! And we *know* we want to coexist that with some flavors of RTP.

> A number of RTP sessions over SHIM will be able to share the lower layer
> transport (UDP) with DTLS/SCTP, more from the perspective that it must
> be able to share it with DTLS and STUN to make ICE and DTLS-SRTP work
> than anything else.

IIUC the demux of shimmed RTP from DTLS/SCTP is exactly the same as for 
unshimmed RTP.

> Colin Perkins and I did privately discuss ways of signalling the SHIM
> solution in Orlando and put together a strawman. I can share it here to
> see what input you have.

IMO we don't need to spend much time on it now, as long as we can see a 
way forward if/when we get around to working on it.

> 1) We would have one m= line to describe the SHIM's transport itself, i.e.
> m=application 12345 UDP/SHIM *
> a=candidate ...
>
> 2) Each RTP session would be described normally with or without bundle.
> Although we prefer to avoid BUNDLE, but that would depend on the rest of
> discussion on what recommendation for multiple m= lines description of
> one RTP session means.
>
> The port numbers on the m= lines would be used as SHIM IDs. They anyway
> have to be unique for fallback if BUNDLE is not supported.
>
> 3) The media descriptions involved in one SHIM will for clarity be
> indicated using a SHIM specific grouping semantics.
>
> 4) If SHIM is supported as determined by first round, the media
> descriptions can be cleaned up and any unnecessary transport information
> can be removed in second round to verify that middleboxes don't
> misunderstand that SHIM is being used and that is the only main
> transport parameters for the streams put on that SHIM.
>
> This proposal is intentionally not requiring BUNDLE because we want to
> enable the fallback from SHIM to Individual sessions over different
> transports if SHIM is not supported. If BUNDLE would be included then
> then choice of fallback from SHIM might become BUNDLE, which in most
> cases is not desired. You are using SHIM because you want different RTP
> sessions, not have everything put into one RTP Session.

This smells like there are as many rat holes to pursue as there have 
been in bundles without SHIM. I doubt we want to go there now.

> Sorry if I missed something important in earlier discussions. I am still
> catching up on MMUSIC and I haven't managed to read it linearly.

Hard to tell. :-)

	Thanks,
	Paul

> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>