On 7/25/2012 6:13 AM, Michael Welzl wrote:
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.
Correct, this was an issue I've been driving towards and promoting (without an actual proposal how to do more than share among the media streams).
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).
This is similar to (but more standardized than) some ideas about coordination among senders we've been thinking about in Mozilla
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.
Or a browser's HTTP engine interacting with the FSE (even if there are no media streams at that time). -- Randell Jesup randell-ietf@jesup.org