Re: [rtcweb] How to multiplex between peers

[Magnus Westerlund <[e-mail]>]

As an Individual

Follow up inline

On 2011-07-20 02:43, Cullen Jennings wrote:
> On Jul 19, 2011, at 8:11 , 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.
> 
> Uh, we already demux STUN, RTP/RTC, DTLS-SRTP based on first byte and
> this is no big deal and is sort of water under the bridge at this
> point. But this first byte multiplex issues is a red herring to this
> topic, what happens with the demux of these protocols does not really
> have much to do with how to demux the different RTP sessions.

I agree that we currently have a design that multiplex the three above
protocols onto the same lower layer when one uses ICE and DTSL-SRTP.
However, the proposal in the WG is pilling on to this, but suggesting to
add at least one protocol to the mix, maybe more if we do reliable in
the future. The more independent protocols there is in the mix the
bigger the risk is that we get a failure in the demultiplexing.

>From my perspective this is not a red-herring at all. It is about good
and future proof design.

Both this issue and the RTP session multiplexing needs to be considered.

> 
>> 
>> 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.
> 
> A bunch of us our proposing SSRC. We not seeing any problems with it.
> I rather having this discussion be concrete around the specific
> proposal on the table and not just some abstract it might be hard to
> find something.

The proposal on the table is to change the semantics of the SSRC field.
So that it contains one part that is session identifier and another that
is stream identifier. This have substantial impact on the RTP/RTCP
specification and the implementation. To the degree where what you have
is not any longer compatible with RFC 3550. It looks like RTP/RTCP but
it isn't any more.

We have documented the impacts of your proposal in Sections 2.2.1 and
3.3.1 of
https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=1

So from my perspective the proposal on the table is a complete no-go.
And I have been thinking trying to find a proposal that wouldn't result
in all these issues and still be internal to RTP. And I haven't found
one yet. That is why I flag this.

If there is a solution that doesn't have as serious impact I do want
AVTCORE to standardize it.

> 
>> 
>> 3. We likely need a multiplexing layer anyway if we want a fall
>> back over WebSockets or HTTP.
> 
> Not really - I think this is best done by making another TURN like
> protocol that is compatible uses WebSockets or HTTP as the underling
> transport. An architecture like this means that  that protocol is
> selected unilateral by the endpoint and used to get through that
> endpoints  firewalls. Both clients don't have to agree to do the same
> thing - just like If I am using a TURN and you are not, we can still
> have a call. Avoid a bilateral solution where possible make it much
> easier to roll out.

Well, it still needs to put out compatible flows. And if we have a
multiplexing layer that becomes equally easy.

> 
>> 
>> Thus we see this a very fragile mechanism that creates additional
>> work overhead and large uncertainties in when it would be
>> available.
> 
> This all sounds sort of doom and gloom but lets talk about real
> problems.
> 

Timing is a real problem. If we want to do multiplexing in RTCWEB 1.0 we
need to pick what is ready and available. We can't go around proposing
new things that are complicated. Changing the SSRC field semantics in
RTP/RTCP is a complicated thing.

We will have tons of discussion of what the requirements really are for
a more generally applicable solution. Not one that barely meets RTCWEBs
needs, when we know the minute this goes out the door a lot of other RTP
using services and applications would like to use it. The teleprecense
work in CLUE is just one example. There will be a bunch. Thus AVTCORE
needs to have a serious discussion of what the requirements are. Then we
will discuss what the architectural implications are of any proposal.
Review what existing functionality we are ready to break and likely need
to replace. What the issues are with gatewaying between old and new
semantics.

Cullen, you are an experienced IETF, you have been an AD for RAI. What
do think the probability is that this discussion has concluded and
resulted in an IESG approved specification before December 2012?

>> 
>> 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.
> 
> The problem with this is that if you are talking to a device that
> does not support this you forever have to go through some
> intermediary gateway that strips the byte. Just like turns servers,
> this reduces the user experience by adding latency and jitter and is
> expensive to run due to the bandwidth required.

Isn't that gateway going to be present anyway in most case. I think the
ICE connectivity checks are one thing that will force a gateway in many
cases. In the cases it isn't needed, then you can skip the multiplexing
in that case to reach the legacy.

Would it not be better to have a clean explicit design for how to
multiplex protocols between peers that can be used in RTCWEB and other
future applications that doesn't drag our past mistakes into the design
and forever prevent simple expansion with new functionality.

The cost, a low one from my perspective is to say that legacy don't get
the benefits of multiplexing. A feature they anyway are not going to get
unless they use a gateway or are updated to be RTCWEB compliant.



> 
>> 
>> 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.
> 
> This has the same problem as above with the added problem of I am not
> aware of a good (meaning widely tested) DCCP implementation in user
> land and to be deployable this pretty much needs to be all user land.


Yes, I do agree that it needs to be a user-land implementation in the
browser until DCCP becomes available in the OSes. But that is true also
for all the alternatives that so far been discussed. TFRC in RTP will be
as much user-land as DCCP over UDP with TFRC.

The big difference is that we either have a well reviewed and by the
community and IESG approved specification in DCCP. Or we create
something our selves that needs to go through all that review and will
be even less tested than DCCP is.


> 
> 
>> 
>> We invite people to consider these proposals or suggest better 
>> alternatives of explicit multiplexing. But I hope we can avoid a
>> serious mistake and select implicit multiplexing.
> 
> I'd like people to start talking about what the actual serious
> mistakes of implicit multiplexing as specified in the SSRC proposal
> are. Ok, Have I thrown the gauntlet down enough :-) Really, I'm just
> not getting what the problems are - if I understood the problems, I
> might have a different view point on this.
> 

Please do read the latest version of
https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=1

We have expanded on the discussion, both about the particular proposal
and the general issues with multiplexing is RTP.

If you can give some hint what in that argumentation you don't
understand we can try to explain in some other way.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------