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

[Michael Welzl]

On Aug 3, 2012, at 4:05 PM, Harald Alvestrand wrote:

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

I totally agree - I think we should just define the concept of an FSE,  
with what goes in and out (and how it's maintained), which is already  
hard enough. Where on the host the FSE is located should be up to the  
implementation. This means, you could have an FSE within the browser,  
as you suggest, plus (optionally) an FSE in the OS, which could then  
deal with coordination between processes. All of that should be  
optional and up to the implementor, and FSE implementations at both  
levels could fit the standard as long as we only define the interface.


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

True. I like to think of RFC2140 as a logical starting point, even  
though that's quite different in several ways (window-based, about  
TCP, ..). But yes, this is the tricky bit.


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

I think that's an easy one. From past experience, I think the IETF can  
and will not agree on a shared bottleneck detection mechanism. So I'm  
convinced that we should leave this open in the spec, and allow for  
any algorithm to do it -- but: flows that are considered to share a  
bottleneck should be returned by the FSE.

At first, this probably means that FSEs will only be implemented in  
browsers, where bottleneck-sharing is known because it's the result of  
multiplexing data over the same five-tuple (UDP port pair). (assuming  
anything else would also mean that no congestion control for RTP over  
UDP could be done, I think - and so it's simply *assumed* that these  
flows share a bottleneck).

Later, people could put FSEs elsewhere, e.g. in OS kernels or run them  
as a demon, and then, for that, they could use a shared bottleneck  
detection mechanism of their choice. There are several such mechanisms  
available, and it's perhaps worth surveying them and documenting that  
somewhere. Of course, 100% reliability doesn't exist...  but my guess  
is that letting the FSE rely on a *mostly* reliable mechanism is  
better than assuming "no shared bottleneck" all the time. But anyway,  
I think we should leave this up to implementers.

Cheers,
Michael