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

[Michael Welzl]

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.


> However, for a set of hosts that does have some knowledge of the relative flow priorities, those hosts now have the information to "do the right thing". There are many proprietary examples of hosts that do this today, but they are all silo-ed and do not interoperate. The best example I can think of is in the IPTV world. There are N hosts behind a constrained last mile. They know about each other's streams. They know about the bandwidth allocated to the video flows, and the system knows how to mark packets. The hosts simply co-operate to stay below the constrained link BW.
I'm not saying I wouldn't *like* such networked FSE usage... maybe one 
can just leave this possibility for the future and only agree on the 
minimum necessary things: usage within a single host, what to store, how 
to use it (as recommendations) for now. This wouldn't exclude extending 
the system to do what you describe above in the future.


> However, we do need to be careful to stay away from mandating very heavy-weight methods. Old-style formal admission control methods are not desirable, IMHO. History has shown that such methods simply do get deployed into the areas in which we need to have flow visibility.  As long as we think in terms of advisory messages between the network edge and the hosts, I think we are on solid ground. If a given set of hosts, on a given network want to invoke draconian admission control measures as a result of Flow State Exchange, that is up to them - but out of scope.
I couldn't agree more. Advisory messages is exactly what I had in mind.

> In any case, the individual flows MUST still adhere to the basic congestion control algorithms that we are going to embark upon. There may be flows in the same QOS bucket that are not participating in the FSE algorithm. Even in that scenario, FSE data could be used by the participating hosts to decide which stream gets throttled.
Yes!

Michael