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

[Randell Jesup]

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 at jesup.org