Re: [rtcweb] To multiplex or not!

[Cullen Jennings <[e-mail]>]

On Jul 20, 2011, at 4:08 , Emil Ivov wrote:

> На 20.07.11 02:05, Cullen Jennings написа:
>> I'd like to see it that devices MUST support multiplexing and I'd
>> probably be in favor of also MUST support non multiplexed flows. The
>> multiplexing is a big advantage for any device that needs to deal
>> with NATs so I suspect many "legacy" devices would be moving to this
>> even if there was no need to deal with the browser like devices. I
>> also think that allowing this type of multiplexing will make firewall
>> traversal easier where a device can configure a firewall to open just
>> one specified port and use it for RTP.
> 
> I don't really agree with this part. Devices would still need to handle
> candidates that come from  STUN, TURN, UPnP, host IPv4, host IPv6, and
> potentially VPN, MIPv6 and other tunnelling mechanisms. Whether or not
> this only happens for a single component/stream doesn't really simplify
> code does it?
> 
> According to my personal experience with our work on ice4j.org, managing
> multiple checklists was far less resource consuming than implementing
> TURN tunnels and persmissions, STUN multiplexing, synchronisation and
> even getting pacing right.


Ahh, I think we have come to the key issues here - perhaps I have not been explaining myself very well. So in your experience roughly how long does it take to set up a for two scenarios using ICE as is today. 

First scenario: I have two devices that want to set up a single audio stream and they each have the candidates from: local v4 IP address, v4 stun, v4 turn, local v6, turn v6. Obviously they could have a lot more but that seems like a reasonable starting point. 

Second scenario: same as first address wise but instead of a single audio stream they want to set up a single audio stream  to a conference bridge plus 7 video streams for the video from the 5 people on the bridge plus a presentation stream and stream of video from active speaker. I don't really care much about the scenario other than there are 8 streams being set up. But this type of scenario is becoming very common for multi party video chat as it allows you to see perhaps small versions of everyone plus a large version of active speaker. 

My experience is the answer to the first scenario is not as quick as you would like and the answer to how long the second takes is about 8 times longer than the first one. You might do a bit better than that depending on how clever your implementation is but it still a lot longer. 

I totally agree with you that multiplexing may not hugely simplify the code and you still have to deal with the hard parts to implement. WHat is helps with is it makes the second scenario take exactly the same time as the first scenario because instead of taking 8 times a long. It's purely a user experience thing. Does that make sense? 


> 
> <snip>
> 
>> The primary reason I want multiplexing is the time to set up all the
>> ICE connections. The fact of the matter is that NATs limit how
>> quickly you can create new flows. If all you need is something simple
>> with just 2 flows, one for audio and one for video, this is workable.
>> But as soon as you move to trying to have a transition strategy from
>> V4 to V6 and multiple person video or even just multi screen video,
>> the user experience goes downhill rapidly.
> 
> I agree more with this argument, although freezing candidates
> significantly brings down the overhead incurred by having multiple
> streams and components and I am not sure that the actual win here would
> be good enough to pay for implementing multiplexing and for breaking
> interoperability with those that don't have it.

Use multiplexing would be negotiated over the SDP, just like rtcp/rtp mux is negotiated today, so it would not break interoperability with stuff that did not support it. 

> 
>> Much of the IETF thinking around ICE was done on the assumption that
>> ICE could be done before ringing started or during ringing but the
>> deployments I am seeing are moving more towards not doing ICE until
>> after a call is answered. There are many reasons for this but one of
>> them is that if Alice calls Bob, and Bob is on a mobile internet
>> device, you don't want to reveal Bob's location to Alice before Bob
>> even decides to answer the call. Given an IP address more or less
>> reveals location these days that a bit of issues to do ICE before
>> answering. This puts more pressure on being able to do ICE quickly
>> for a good user experience.
> 
> Agreed, but is multiplexing the only way of bringing the time down? The
> XMPP crowd for example has been using a mechanism that allows candidates
> to be sent as they become available rather than wait for all harvesting
> to complete. Maybe this is worth exploring and integrating in the
> official ICE (although I don't see how it would work with SIP).

I am a fan of sending candidates as they become available but I don't think this helps much as most devices can gather the addresses before the user even initiates a call and the gather it typically very quick relative to the rest of the ICE process. 

> 
> Cheers,
> Emil
> 
>> 
>> Cullen <with my individual contributor hat on>
>> 
>> On Jul 19, 2011, at 7:28 , Magnus Westerlund wrote:
>> 
>>> Hi,
>>> 
>>> This email is as an individual contributor.
>>> 
>>> I want to get started on the discussion of the Multiplexing of the 
>>> various protocols over single lower layer transport flow, such as a
>>> UDP flow. I will attempt to split up the questions into different
>>> emails.
>>> 
>>> The first question I think is reasonably easy to get answered, but
>>> I think it is time we determine if my belief in the answer is
>>> correct or not.
>>> 
>>> The traffic between two RTCWEB peers from the various components,
>>> such as RTP sessions, datagram service:
>>> 
>>> a) MUST be sent as Individual flows for each component.
>>> 
>>> b) MUST be multiplexed into a single transport flow.
>>> 
>>> c) SHOULD be multiplexed into a single transport flow, but the
>>> RTCWEB peer MUST be able to send them as individual flows.
>>> 
>>> I would love if people can indicate their choice or preferences.
>>> 
>>> I personally prefer A as it it is simplest in all aspect except the
>>> NAT traversal. - It allows for flow based QoS. - It is the what the
>>> implementation that exist mostly do - Signaling protocols that
>>> exist support it, no extra functionality - People are used to the
>>> concept - It minimizes the difference to legacy.
>>> 
>>> Thus it is the quickest road to define something with the least
>>> formal push back and concern over maturity of any solution.
>>> 
>>> The downside with B and C is that we do have to solve the
>>> multiplexing and get an agreement that gets through all the
>>> hurdles.
>>> 
>>> Of these two opens I do prefer C.  Although it results in the
>>> extra complexities of having both alternatives, it will give us
>>> both a fallback, flow based QoS and better legacy support.
>>> 
>>> Now it is your time to make your opinion heard!
>>> 
>>> 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] 
>>> ----------------------------------------------------------------------
>>> 
>>> 
>>> 
> _______________________________________________
>>> rtcweb mailing list [e-mail] 
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> 
>> Cullen Jennings For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>> 
>> 
>> _______________________________________________ rtcweb mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> -- 
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> [e-mail]                        PHONE: [phone]
> http://jitsi.org                       FAX:   [phone]
> 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html