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

[Stefan Holmer]

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<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/4bbd04bc/attachment.html>