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

[Michael Welzl]

nah. read the fine print - in the middle of my text, i was careful to  
insert a comment saying the following:

**
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 *really really* isn't the same.


On Jul 25, 2012, at 8:07 PM, Eggert, Lars wrote:

> Sounds a lot like RFC 3124?
>
> Lars
>
> On Jul 25, 2012, at 6:13, Michael Welzl <michawe at ifi.uio.no> 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.
>>
>> 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).
>>
>> 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.
>>
>> Alternative implementation (not as good, but simpler, and just to  
>> show the flexibility): RTP 1 uses its own CC, RTP 2 uses its own  
>> CC, but they feed the priority they got "from above" into the FSE  
>> and read each other's priority and total sending rate from there,  
>> to adapt their increase/decrease behavior accordingly, leading to  
>> the desired total behavior on the wire.
>>
>> 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...  and implementations could provide information  
>> about which flows share a bottleneck based on measurements, not  
>> only because of the UDP 5-tuple, without requiring to standardize  
>> any of that. But the FSE itself would have to be there.
>>
>> What do you all think?
>>
>> Cheers,
>> Michael
>>
>> -----------------------
>>
>> (*) The only prioritization solution that I can think of which  
>> would not require something along the lines of an FSE would be  
>> prioritized congestion control, i.e. giving weights to something  
>> like MulTCP, MulTFRC ...   which means that the fairness you get is  
>> essentially what flows produce, as the result of fighting it out on  
>> the bottleneck. This will create more delay than any FSE-based  
>> solution, working against one main goal of all of us here: reduced  
>> delay.
>>
>> _______________________________________________
>> Rtp-congestion mailing list
>> Rtp-congestion at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion