On 11/4/2011 9:55 PM, Wesley Eddy wrote:
I think the high-level requirements around congestion control are basically good, but could be tightened up or clarified a little bit more.
Copying them from the draft, and commenting on each one below:
1. All WebRTC media streams MUST be congestion-controlled. (The same requirement apply to data streams)
I would clarify this as: """ 1. All WebRTC media or data streams MUST be congestion-controlled using an algorithm specified in an IETF Standards Track RFC.
The ideal algorithm will have a body of knowledge or literature studying its performance in the Internet, or using testbeds, simulations, analytical models, or other means, whose results motivate its use for WebRTC media by meeting other requirements. """
Without that clarity, just any random algorithm could meet the requirement, even if its properties were unknown. I think that would be unfortunate.
At first I thought saying "Standards Track RFC" might be setting the bar a bit high, but when you consider that the rest of the RTCWEB charter includes Proposed Standard mechanisms, then using anything but a Standards Track congestion control protocol would seem to be inappropriate.
It also would mean probably years of delay in publishing an RFC, since I believe no existing standards-track CC algorithm will cover our needs. This standardization effort cannot afford years of delay; it can't afford a single year of delay. If we don't standardize it first, the vendors will go ahead anyways and we'll be stuck with having to document whatever defacto standard they've created. (*Note - I work for one of the vendors; I'm speaking with my contributor hat on.) It also means that innovation and improvement cannot practically occur within WebRTC; the algorithm will be locked in. I'll note that while you say that it must be a Standards-Track RFC, implying the implementer has a choice, in reality since a Standards-Track congestion control algorithm includes not only the bandwidth estimation but also the transmission of that to the sender and the sender's reaction, so everything would have to be locked-down and specified up-front. My suggestion is to specify the data available (which is mostly loss data and arrival/delay data) and specify the mechanism (RTCP-FB packets) to tell the sender what you need them to do, and specify the result (it must be congestion-controlled if possible and must be reasonably fair to TCP/TCP-like flows). Beyond that, let the rest of the actual algorithm be a point of innovation, though a baseline algorithm will be suggested based on a modified version of Harald's draft. These algorithm(s) certainly can be standardized once ready, but requiring that *first* is a problem, IMHO. And standardizing them could take a Long Time.
2. The congestion algorithms used MUST cause WebRTC streams to act reasonably fairly with TCP and other congestion-controlled flows, such as DCCP and TFRC, and other WebRTC flows. Note that WebRTC involves multiple data flows which "normally" would be separately congestion-controlled.
This is good, but not quite right, and not very specific. To make it correct, DCCP isn't an algorithm of its own, so it shouldn't necessarily be mentioned without reference to an appropriate CCID, and "act reasonably" should be more quantitative.
An improvement would be something like: """ 2. The congestion control algorithms used MUST cause WebRTC streams to be able to detect packet losses within several RTTs and reduce their sending rates in accordance with the detected loss event rate. """
There's an inherent assumption here that the CC algorithm is loss-based, which I'm *strongly* hoping to avoid. No loss-based algorithm can produce good results for RT communication on the open web with "bufferbloat" routers in the chain. Even without bufferbloat you'd end up with sub-optimial to bad results using loss-based algorithms. (See below about delay-sensitive algorithms)
3. The congestion control mechanism MUST be possible to realize between two indendently implemented WebRTC end-points.
If you accept the Standards Track requirement above, then this one becomes unnecessary!
4. The congestion control algorithm SHOULD attempt to minimize the media-stream end-to-end delays between the participants, by controlling bandwidth appropriately.
This one is interesting, it says that we prefer congestion control with a delay-based component, if I understand correctly. If that's true (and I think it is), I think it should be elevated to a MUST, for the reason that we suspect concurrent delay-sensitive flows will be present, and any flow creating delays will impact the others. So, we should say: """ 4. The congestion control algorithm MUST attempt to minimize the media- stream end-to-end delays between the participants, by detecting persistent increases in end-to-end latency and adjusting its sending rate in an attempt to reduce latency due to queueing or other contention. """
We absolutely do want to minimize end-to-end delay; without that this effort is a failure. MUST is ok with me (though it's MUST attempt, so one should take "MUST" with a grain of salt). I don't agree with your rewording, since that starts to specify the mechanism used to achieve the desired result. I want to require the result, and don't care how it's achieved so long as its interoperable.
5. The congestion control SHOULD allow for prioritization and shifting of banwidth between media flows. In other words, if one flow on the same path as another has to adjust its bit-rate the other flow can perform that adjustment instead, or divided between the flows.
I like the intent; my suggestion is: """ 5. The congestion control SHOULD allow for flow-based prioritization and sharing of the overall sending rate between multiple flows *between the same two endpoints*. In an ensemble of related flows, this is intended to allow more elastic flows to adjust their rates rather than less elastic flows, causing less disruption to the user experience while producing the same ensemble effect on the sending rate. """
I'll be interested to hear what others think of these suggestions! ;)
That seems good to me. -- Randell Jesup randell-ietf@jesup.org