Re: [rtcweb] To multiplex or not!

[Colin Perkins <[e-mail]>]

If you're not doing network-based QoS to prioritise certain flows, then this is requires two bidirectional UDP flows: one for the audio and one for video, using the standard RTP mechanisms (which is what I understand Magnus' option A to be).

Colin


On 20 Jul 2011, at 10:49, Harald Alvestrand wrote:
> Magnus, I cannot parse your list of choices.
> 
> In the case where you have
> 
> Sender A
> Recipient B
> Three video streams going from A to B
> Three audio streams going from A to B
> One video stream going from B to A
> One audio stream going from B to A
> 
> with the application not requiring the network to treat the packets any differently, and with the application using the CNAME mechanism to match audio streams with corresponding video streams
> 
> it is completely unclear to me whether your choice A) requires 8 transport flows, 4 transport flows or 2 transport flows, and it is completely unclear to me what C) actually means. (I assume "transport flow" = "RTP sessions" here)
> 
> Please - can you clarify what your question is intended to mean?
> 
>                 Harald
> 
> 
> On 07/19/11 16: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
>> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb



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