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

Harald Alvestrand harald at alvestrand.no
Sat Aug 4 01:05:08 CEST 2012


On 07/26/2012 03:36 AM, Michael Welzl wrote:
> On 7/26/12 12:14 PM, Bill Ver Steeg (versteb) wrote:
>> I like where this is going, as long as we understand that any FSE is 
>> advisory information that may or may not be used by a given set of 
>> hosts.
>>
>> One underlying question is -- what actions will take place as a 
>> result of this information exchange? I do not think that this is a 
>> black and white question, and I think this is OK. As long as the 
>> behavior is "do no worse than if the FSE did not take place", we have 
>> not lost anything. In other words, if this information is made 
>> available to the hosts, and the hosts do not do anything with it - it 
>> is the exact same behavior as we have today.
> ACK to all that, except that, to keep things simple (and *only* for 
> that reason), I actually considered the FSE to be located directly on 
> the host where it's used. That is, no FSE server that multiple clients 
> are talking to. No protocol for accessing it, only an agreement about 
> what information to read/store, and usage recommendations.
For a first cut, I'd go even further and put it within a single process 
(the browser is an obvious candidate). This is very simple to realize 
without the cooperation of anyone else, as long as the information is 
available from the congestion control machines managing the individual 
flows.

What to store is interesting - even the key is a good question; should 
one store from/to/protocol/DSCP as observed on incoming packets, 
from/to/protocol/DSCP as inferred on the sending side, or something else?

I'm very unclear on what algorithms one should run to detect that two 
flows are experiencing congestion at the same bottleneck (or not).



More information about the Rtp-congestion mailing list