Re: [rtcweb] To multiplex or not!

[Justin Uberti <[e-mail]>]

On Tue, Jul 19, 2011 at 7:28 AM, Magnus Westerlund <
[e-mail]> 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:
>

To be clear, we are talking about different RTP sessions, as opposed to
different RTP sources within a single RTP session, correct?


> 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.
>

For video applications, it's not clear that flow-based QoS is sufficient, as
some packets are of higher importance than others. Diffserv markings allow
per-packet QoS to be applied, but this could be done even in a multiplexing
scenario.


> - 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.
>

I agree that existing implementations will need to change to support this.
However, is there a large enough base of deployed endpoints that support a)
multiple RTP sessions and b) the other RTCWEB constrains (ICE, etc) to make
this a significant concern?


> 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
>