Re: [rtcweb] How to multiplex between peers

[Matthew Kaufman <[e-mail]>]

On 7/19/2011 8:11 AM, Magnus Westerlund wrote:
> 1. We have 4 or more protocols (The possible set of protocols include:
> STUN, RTP/RTCP, Datagram, and DTLS-SRTP. There is likely future
> extensions, like reliable protocol)  that needs to be identified and
> demultiplexed. A single extension in one of these protocols can cause
> the whole house of cards to come tumbling down.

Multiplexing RTP, RTCP, and STUN on the same port already needs to keep 
working for lots of other reasons, we can leverage those reasons.

draft-kaufman-rtp-compatible-data suggests that the data service can be 
multiplexed with these as well, in a way that is protected by the same 
things that protect the above.

> 2. It will require one to find an RTP internal session multiplexing
> mechanism. This is likely not easy or causes a fork of RTP into two
> non-compatible versions. In addition such a mechanism needs defining
> which takes time, likely substantial time as there is quite a lot of RTP
> mechanisms to consider.

There's one, SSRC. Since we already allow two or more audio streams to 
be multiplexed using SSRC, and two or more video streams to be 
multiplexed using SSRC, it really isn't a stretch to allow one audio and 
one video to be multiplexed using SSRC when the two ends agree that this 
works for them.

> 3. We likely need a multiplexing layer anyway if we want a fall back
> over WebSockets or HTTP.

I agree that we currently don't have good agreement of how a TCP 
fallback works for RTCWEB, but it is clearly necessary.

> Thus we see this a very fragile mechanism that creates additional work
> overhead and large uncertainties in when it would be available.

Not any more fragile than RTP+RTCP+STUN on the same port already is.

> We have in our draft:
> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ looked
> at two possible suggestions for explicit multiplexing. Either a thin
> shim layer primarily consisting of a identifier that through negotiation
> is bound to a context, like an particular RTP session or a datagram
> channel.

Adding a shim layer causes two problems:
1. You need to be able to run the system in a way that has the shim 
layer removed when you want to do legacy interoperability.
2. Existing protocol stacks and middleboxes cannot be reused as easily.

> The other alternative we considered was using DCCP over UDP for RTP and
> datagram. That way we got a complete port space for multiplexing
> different purposes for flows. We also got a transport framework with its
> own negotiation, congestion control, a several other features.

Same problem, no matter what the shim layer is.

I've already considered explicit multiplexing. It has lots of 
advantages. But it also fails several of the tests laid out in the 
requirements, and delays implementation and adoption.

So I think we're down to implicit multiplexing, or no multiplexing at 
all. And when we run out of IPv4 NAT mappings, you'll understand why 
multiplexing should be in there.


Matthew Kaufman