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

[Eggert, Lars]

Sounds a lot like RFC 3124?

Lars

On Jul 25, 2012, at 6:13, Michael Welzl <michawe at ifi.uio.no> 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.
> 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4361 bytes
Desc: not available
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120725/b80090d3/attachment.bin>