Re: [rtcweb] To multiplex or not!

[Colin Perkins <[e-mail]>]

My preference is for option A: send each RTP session on a separate lower layer flow (e.g., a separate UDP flow). Yes, this means that your typical multiparty audio/video conference uses two UDP ports rather than 1, but I do not believe this is a significant problem, since most browsers open far more than 2 TCP ports simultaneously when fetching web resources.

That said, I understand the desire to reduce ICE negotiation times. If this is a real concern (and I'm not convinced it should be, since I don't see that this adds more than 1 RTT to the negotiation in the usual case), then some means of explicitly multiplexing RTP sessions might be useful to develop. I do not believe SSRC-based multiplexing of RTP sessions works though: we would need to develop a multiplexing mechanism that conforms to RTP semantics, or get AVTCORE to agree to a change in RTP with all the backwards compatibility issues that raises.

Colin



On 19 Jul 2011, at 15: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


-- 
Colin Perkins
http://csperkins.org/