Re: [rtcweb] To multiplex or not!

[Cullen Jennings <[e-mail]>]

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. 

The number places where RSVP is usable does not really overlap with places one uses ICE so it does not bother me in the slightest that RSVP won't work with this. It's pretty easy to imagine an extension to RSVP to support reservations based on SSRC inside the flow. Diff Serv based qos will work which is what more commonly used in situations where we are using NATs. 

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. 

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. 

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