On Jul 25, 2012, at 6:51 PM, John Leslie wrote:
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.
For rtcweb, it is: it's requirement F34 in draft-ietf-rtcweb-use-cases- and-requirements
We do desire that some flows be treated as more delay-critical than others; and IMHO that's not the same thing.
I disagree with this separation of treatment. As soon as one flow is delay-critical, and as long as we cannot 100% know (we can hope, but IMO never know, within the soon-deployable- world...) that traffic isn't separated in the network, we must ensure that all congestion control is designed to such that delay is kept minimal. Otherwise, your own delay-critical flow will suffer from your own not-so-delay-critical flow... that makes no sense.
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".
Yes, but that doesn't contradict my proposal.
... 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
I agree, functionality-wise, and apologize for using the word "layer" here: I didn't mean this in the sense of network layers, but in a more physical sense - as in "where in the stack" or "where in the OS". I guess "level" would have been a better choice of words.
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...
Oh yes! This is as sketchy as it gets, a totally new idea, shared with you straight away, to see what people think.
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.)
Okay, I was thinking sender-side here, but why not...
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>
Cheers, Michael