Re: [rtcweb] To multiplex or not!

[Harald Alvestrand <[e-mail]>]

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
>