[R-C] Some high level requirements and discussion topics in draft-ietf-rtcweb-rtp-usage-01

[Wesley Eddy]

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