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

[Michael Welzl]

It looked interesting, but more complicated to me. By focusing on the sender side (which I think we can do, in our case) the problem space gets easier to handle.


On 6. aug. 2012, at 13:55, Stefan Holmer wrote:

> Yuchung Cheng talk about "Client-aided Congestion Management for TCP" in ICCRG session seemed somewhat related to this. Not sure what can be reused, but the concept looks similar.
> 
> /Stefan
> 
> On Sun, Aug 5, 2012 at 4:53 PM, Michael Welzl <michawe at ifi.uio.no> wrote:
> 
> 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
> 
> 
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120806/19d8946a/attachment.html>