[RTW] RTP Session Multiplexing (Re: Fwd: I-D Action:draft-perkins-rtcweb-rtp-usage-00.txt)

[Jonathan Rosenberg]

A few comments on this.

One of the primary arguments in favor of UDP/port muxing of sessions is
backwards compatibility with existing RTP-based endpoints. I think it is
important to point out that - even though backwards compatibility with
existing RTP-based equipment is clearly desired - it is not yet clear that
it is achievable within the security context of the browser.

If we discount backwards compatibility, there are two high level reasons
to do UDP muxing. One is to enable reuse of existing specifications (FEC
for example) and the other is because of functional benefits (of which I
see only one really - usage of differing network paths for different
session types). The multi-path argument to me is really the compelling
one. I'm in favor of giving the maximum flexibility for application
designers, and this is clearly a point of flexibility.

However, I do think we need a multiplexing layer. Being able to send
application data between the browsers directly will have many uses. Games
have been mentioned as one use case; even for a pure voice and video calls
the usage of p2p messaging will prove invaluable for enabling innovation
in the area of real-time feedback and control mechanisms. The browser
environment will make these new use cases easy to deploy, and I think
we'll see a lot of them. I think we're also going to see a LOT of video
usage. At Skype, around 40% of our Skype-to-Skype calls are video. For
these reasons, I think we want to include a multiplexing mechanism.

Besides adding setup delays because of the need to run more port opening,
it increases network traffic, and most importantly, increases the
consumption of port bindings on the NAT. I think we need to start treating
port bindings as a commodity which will grow scarcer over time. Indeed,
I'd go so far as to say this - designing something new like browser RTC -
without enabling operation on a single port in order to conserve NAT
bindings - is irresponsible and potentially harmful to the Internet. Its
usage should be strictly for backwards compatibility or for the cases in
which it is a necessity for functional reasons (e.g., multiple network
paths).

Putting these together, it is my view that we should allow for IP/port
based demux of differing sessions, but we should also design a demux layer
that can enable everything on a single IP/port. And furthermore, the
latter should be the preferred technique for browser-to-browser
communication in the base case.

Thanks,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Skype Chief Technology Strategist
jdrosen at skype.net                              http://www.skype.com
jdrosen at jdrosen.net                            http://www.jdrosen.net




On 3/9/11 5:20 PM, "Magnus Westerlund" <magnus.westerlund at ericsson.com>
wrote:

>Harald Alvestrand skrev 2011-03-08 13:10:
>> Short summary, to see if I understand Magnus correctly:
>> 
>> If we want to use RTP over UDP as it currently stands, we have to
>> multiplex on port number. If one sender sends two media streams to one
>> recipients, at least one part of the <sender ip:port>:<recipient
>> ip:port> 4-tuple has to be different.
>
>Not strictly, I would say that both using unique 5-tuples and an
>explicit multiplexing layer is fine from RTP perspective. Explicit
>multiplexing layer is already used, for example when sending RTP over
>RTSP's signalling TCP connection [RFC2326].
>
>> 
>> The alternatives involve modifying protocols that are not otherwise
>> within the scope of this working group.
>
>Well, the charter isn't approved yet. And I think there will be need for
>a RTC-WEB WG to in some cases agree that some work is needed. Then the
>question of where can be raised, within the WG, in some other WG or in a
>new WG. Sure, this must be weighted against the time it takes to
>complete the work.
>
>An explicit multiplexing layer needs not be complex if one keeps the
>requirements simple. Thus if it is considered necessary then I think it
>can be developed in the RTC-web WG. If using different UDP flows are the
>preferred way, then that comes at a different set of trade-offs. Airing
>these trade-offs and gaols are likely the right way of achieving at
>least rough consensus going forward here.
>
>I want to be clear that I have not yet any strong view on what the right
>choice is here. Except that I don't want to redesign RTP now and for
>this. Secondly, I want to ensure that RTP sessions can be used, but that
>is just of question of ensuring that there some explicit indicator of
>what RTP session a particular packet belongs to.
>
>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 at ericsson.com
>----------------------------------------------------------------------
>_______________________________________________
>RTC-Web mailing list
>RTC-Web at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/rtc-web