Michael Welzl <michawe@ifi.uio.no> wrote:
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'm not positive that's exactly what's desired. We do desire that some flows be treated as more delay-critical than others; and IMHO that's not the same thing. It is perfectly legitimate to collect congestion indications for any and all traffic known to share the same path, but make data-rate reductions according to an application-layer algorithm (which could indeed be as simple as priority values for each sub-stream). So long as the overall data-rate is properly reduced, there's no question of "unfriendlyness".
... 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.
It _would_ need to receive congestion indications -- that seems to imply that the FSE belongs at transport layer.
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.
Your hands are waving... I suggest assuming the receiver's transport layer-stack(s) coordinate their congestion indications (by a function-call, for example) and receive instrution as to how much data-rate-reduction each of them should signal to the corresponding sender. (Yes, this does kind-of require greater precision in congestion feedback, but IMHO that's an unmitigated good-thing.)
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...
Yes, this seems to fit the SCTP paradigm nicely... -- John Leslie <john@jlc.net>