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

[Bill Ver Steeg (versteb)]

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. 

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.

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. 

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.

bvs





-----Original Message-----
From: rtp-congestion-bounces at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no] On Behalf Of Michael Welzl
Sent: Wednesday, July 25, 2012 9:13 AM
To: rtp-congestion at alvestrand.no
Subject: [R-C] Suggesting a "Flow State Exchange" (FSE)

Hi all,

This is a "chair hat taken off and thrown into a corner" message -  
very much my personal thoughts, and I'm very curious what you all think:

Starting point: there is a desire to have priorities between flows,  
e.g. in rtcweb, but maybe also between other RTP streams.

I have been arguing that the right way to do this is to have only a  
single congestion control entity, and then realize fairness among the  
flows as a result of scheduling data across them. I still believe that  
this is the right way to do it (and - Randell please correct me if I'm  
wrong - it seems that this is the approach already pursued by  
Mozilla). This thinking led me to propose my all-over-SCTP idea.

Now, I don't see how such a thing could be standardized, especially if  
we don't want to limit ourselves to rtcweb only. HOWEVER: it is clear  
that flows will need information about other flows - such as: what is  
their priority? How many are there, that we can assume to traverse the  
same bottleneck (e.g. because they share the same UDP 5-tuple)? What  
is their current sending rate?

Without having agreed on how to exchange such information, I think it  
will be hard to implement the above fairness solution or any other  
good(*) solution in a standard-conformant way. Therefore I propose  
that we should standardize what I think is the simplest possible,  
necessary element: a "Flow State Exchange" (FSE).

An FSE is a *passive* entity on a host that receives congestion- 
control-relevant information from RTP flows and provides that  
information upon request. It resides on a host, and if we define it in  
the right way it probably doesn't matter at which layer: one could  
have an FSE inside the browser, and optionally have the browser talk  
to an additional system-wide FSE in the kernel. Note that this is not  
the Congestion Manager (RFC3124): the CM was an *active* entity, much  
more complicated to realize, and much closer to the "single congestion  
control instance" idea described above.

With an FSE, a single congestion control instance could be realized as  
follows:
RTP flows => update the FSE.
CC. instance => reads information from the FSE, then controls the  
sending rate per RTP flow and schedules data across the flows.

Alternative implementation (not as good, but simpler, and just to show  
the flexibility): RTP 1 uses its own CC, RTP 2 uses its own CC, but  
they feed the priority they got "from above" into the FSE and read  
each other's priority and total sending rate from there, to adapt  
their increase/decrease behavior accordingly, leading to the desired  
total behavior on the wire.

It's not hard to imagine that this could be extended in many ways -  
e.g. the SCTP data channel could access the FSE to also incorporate  
priorities there...  and implementations could provide information  
about which flows share a bottleneck based on measurements, not only  
because of the UDP 5-tuple, without requiring to standardize any of  
that. But the FSE itself would have to be there.

What do you all think?

Cheers,
Michael

-----------------------

(*) The only prioritization solution that I can think of which would  
not require something along the lines of an FSE would be prioritized  
congestion control, i.e. giving weights to something like MulTCP,  
MulTFRC ...   which means that the fairness you get is essentially  
what flows produce, as the result of fighting it out on the  
bottleneck. This will create more delay than any FSE-based solution,  
working against one main goal of all of us here: reduced delay.

_______________________________________________
Rtp-congestion mailing list
Rtp-congestion at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtp-congestion