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

[Michael Welzl]

On Jul 25, 2012, at 6:51 PM, John Leslie wrote:

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

For rtcweb, it is: it's requirement F34 in draft-ietf-rtcweb-use-cases- 
and-requirements


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

I disagree with this separation of treatment.
As soon as one flow is delay-critical, and as long as we cannot 100%  
know (we can hope, but IMO never know, within the soon-deployable- 
world...) that traffic isn't separated in the network, we must ensure  
that all congestion control is designed to such that delay is kept  
minimal. Otherwise, your own delay-critical flow will suffer from your  
own not-so-delay-critical flow... that makes no sense.


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

Yes, but that doesn't contradict my proposal.


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

I agree, functionality-wise, and apologize for using the word "layer"  
here: I didn't mean this in the sense of network layers, but in a more  
physical sense - as in "where in the stack" or "where in the OS". I  
guess "level" would have been a better choice of words.


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

Oh yes! This is as sketchy as it gets, a totally new idea, shared with  
you straight away, to see what people think.


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

Okay, I was thinking sender-side here, but why not...


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

Cheers,
Michael