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

[Randell Jesup]

On 7/25/2012 6:13 AM, Michael Welzl wrote:
> Hi all,
>
> 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 have been arguing that the right way to do this is to have only a
> single congestion control entity, and then realize fairness among the
> flows as a result of scheduling data across them. I still believe that
> this is the right way to do it (and - Randell please correct me if I'm
> wrong - it seems that this is the approach already pursued by Mozilla).
> This thinking led me to propose my all-over-SCTP idea.

Correct, this was an issue I've been driving towards and promoting 
(without an actual proposal how to do more than share among the media 
streams).

> Now, I don't see how such a thing could be standardized, especially if
> we don't want to limit ourselves to rtcweb only. HOWEVER: it is clear
> that flows will need information about other flows - such as: what is
> their priority? How many are there, that we can assume to traverse the
> same bottleneck (e.g. because they share the same UDP 5-tuple)? What is
> their current sending rate?
>
> Without having agreed on how to exchange such information, I think it
> will be hard to implement the above fairness solution or any other
> good(*) solution in a standard-conformant way. Therefore I propose that
> we should standardize what I think is the simplest possible, necessary
> element: a "Flow State Exchange" (FSE).

This is similar to (but more standardized than) some ideas about 
coordination among senders we've been thinking about in Mozilla

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

Or a browser's HTTP engine interacting with the FSE (even if there are 
no media streams at that time).

-- 
Randell Jesup
randell-ietf at jesup.org