[R-C] Suggesting a "Flow State Exchange" (FSE)

[John Leslie]

Michael Welzl <michawe at ifi.uio.no> wrote:
> 
> This is a "chair hat taken off and thrown into a corner" message -  
> very much my personal thoughts, and I'm very curious what you all think:
> 
> Starting point: there is a desire to have priorities between flows,  
> e.g. in rtcweb, but maybe also between other RTP streams.

   I'm not positive that's exactly what's desired.

   We do desire that some flows be treated as more delay-critical than
others; and IMHO that's not the same thing.

   It is perfectly legitimate to collect congestion indications for
any and all traffic known to share the same path, but make data-rate
reductions according to an application-layer algorithm (which could
indeed be as simple as priority values for each sub-stream). So long
as the overall data-rate is properly reduced, there's no question of
"unfriendlyness".

> ... I propose that we should standardize what I think is the simplest
> possible,  necessary element: a "Flow State Exchange" (FSE).
> 
> An FSE is a *passive* entity on a host that receives congestion- 
> control-relevant information from RTP flows and provides that  
> information upon request. It resides on a host, and if we define it
> in the right way it probably doesn't matter at which layer: one could  
> have an FSE inside the browser, and optionally have the browser talk  
> to an additional system-wide FSE in the kernel. Note that this is not  
> the Congestion Manager (RFC3124): the CM was an *active* entity, much  
> more complicated to realize, and much closer to the "single congestion  
> control instance" idea described above.

   It _would_ need to receive congestion indications -- that seems to
imply that the FSE belongs at transport layer.

> With an FSE, a single congestion control instance could be realized
> as follows:
> RTP flows => update the FSE.
> CC. instance => reads information from the FSE, then controls the  
> sending rate per RTP flow and schedules data across the flows.

   Your hands are waving...

   I suggest assuming the receiver's transport layer-stack(s) coordinate
their congestion indications (by a function-call, for example) and
receive instrution as to how much data-rate-reduction each of them
should signal to the corresponding sender.

   (Yes, this does kind-of require greater precision in congestion
feedback, but IMHO that's an unmitigated good-thing.)

> It's not hard to imagine that this could be extended in many ways -  
> e.g. the SCTP data channel could access the FSE to also incorporate  
> priorities there...

   Yes, this seems to fit the SCTP paradigm nicely...

--
John Leslie <john at jlc.net>