On 11/1/2011 10:52 AM, Magnus Westerlund wrote:
Hi,
We authors decided to put in some text in draft-ietf-rtcweb-rtp-usage-01 around congestion control. See section 8 of https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
We appreciate feedback if we are in error or if it is a good start that can be considered to have WG consensus and be extended upon.
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.
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. """
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. """
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! ;) -- Wes Eddy MTI Systems