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

[Matthew Kaufman]

On 3/7/2011 6:38 AM, Magnus Westerlund wrote:
> Harald Alvestrand skrev 2011-03-07 13:44:
>> On 03/07/11 11:19, Magnus Westerlund wrote:
>>> Hi,
>>>
>>> Colin Perkins, Joerg Ott and I have created this draft about RTC-WEB's
>>> usage of RTP. Feedback and discussion are most appreciated.
>>>
>>> Cheers
>>>
>>> Magnus
>>>
>> Thank you, Magnus!
>>
>> Changing the subject line to take one topic at a time:
>>
>> Section 2.1 is stated almost totally in the negative: "because of THESE
>> considerations, do NOT do that". I have problems parsing that.
>>
>> In the RTCWEB situation, we will commonly have the situation (crummy
>> ASCII art alert):
>>
>>     Participant  ---->   FW  ---->  FW ---->  Participant
>>
>>       ----------------->  Audio -------------->
>>       ----------------->  Video --------------->
>>      ------------------>  Other --------------->
>> <--------------- Audio -------------------
>> <--------------- Video ------------------
>> <--------------- Other --------------------
>>
>> (I am too lazy to add RTCP into the picture)
>>
>> Due to the cost of firewall transition mechanisms, holding many port
>> pairs open is an expensive proposition, so the issue has been raised.
>>
>> Exactly what assignment of streams to<address, port, SSRC, PT>  is the
>> draft proposing that we use?
> The SSRC and PT have well established purposes, SSRC is used for media
> sources, like different cameras or microphones. For multi-party
> communication (especially with central node) they are also needed to
> keep track of the different particpants sources.
>
> When it comes to separating the RTP sessions from each other we are
> actually not suggesting how to solve it. Only trying to say that it
> needs to be solved.
>
> The alternatives I see are:
>
> 1. Use UDP ports as currently done today. Yes, requires to perform NAT
> traversal for several UDP flows. But the question is how big the cost is
> when you already have a good RTT measurement and know which candidate
> pair that worked previously. Without any packet loss that aren't
> introduced by lack of FW and NAT state, this should be possible to
> achieve within 2 RTT + some 20 ms of guard time. Yes, that also assumes
> that you learned your public address and port for this socket before.
> But if that is needed also then 3 RTTs plus some.
>
>
> 2. Add a multiplexing layer. Stick a shim between UDP and the payloads
> in all cases. A single byte should suffice from a number of streams.
> Moves certain scheduling and transmission buffering choices above the
> socket level. Deep packet inspection and QoS will be hurdles.
>
> 3. Change RTP to cope with multiplexing. This is a major effort I think
> as it basically redesigns several aspects of RTP and RTCP. It also hurt
> interoperability with any normal RTP clients. Does also not work with
> any datagram or byte stream service that you want to multiplex also on
> the same UDP flow.
>
> Needs discussion as far as I see it.

This seems like my list of three choices, only restated more clearly and 
with some alternate opinions.

This seems like a good time to note that I have, since posting my list, 
independently found additional reasons to prefer #1, even though the 
NAT/firewall traversal (and state) overhead is higher. This is in 
addition to legacy interop, which is also important. (Though not 
actually that critical for audio-only interoperability, as there will 
likely only be one RTP stream and thus would only be one ssrc if one 
chose to use ssrc for the muxing)

Matthew Kaufman

Matthew Kaufman