Re: [rtcweb] To multiplex or not!

[Randell Jesup <[e-mail]>]

On 7/19/2011 10:28 AM, Magnus Westerlund wrote:
> 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.

C).   I understand the appeal of a).  However, we already have minor 
issues with handling
congestion across multiple streams - i.e. congestion notification goes 
to one flow, but not
generally to the other flows that make up the total traffic between 
these two points.  This
leads to sub-optimal response to congestion, and as the number of flows 
increases this
would get worse.  Now, this really isn't mandated by the 
multiplex/non-multiplex nature; it's
just easier and more obvious when they're multiplexed.

The other big issue is as you add more than a single or two streams, the 
overhead and
side-issues around ICE/etc get more ... interesting.  In particular you 
can get (I assume) cases
where different streams that are meant to be synchronized and follow the 
same route
go over different paths/interfaces.

If we only had to deal with 1 audio stream, or 1 audio and 1 video 
stream, the balance would be
different.  But in the world this spec will work in I strongly believe 
more than 2 streams
will often exist.  (Witness Google's "Huddle").

-- 
Randell Jesup
[e-mail]