Subject: Re: [rmcat] Last Call: <draft-ietf-rmcat-cc-requirements-05.txt> (Congestion Control Requirements For RMCAT) to Informational RFC

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Aug 2014 15:49:02 +0100

On 30 Jul 2014, at 21:47, The IESG <[email-masked]> wrote:
> The IESG has received a request from the RTP Media Congestion Avoidance
> Techniques WG (rmcat) to consider the following document:
> - 'Congestion Control Requirements For RMCAT'
>  <draft-ietf-rmcat-cc-requirements-05.txt> as Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-08-13. 

Apologies for the late response, but I have some extensive comments on this
draft:

- Requirement 1A states that the congestion control algorithm should try to
  keep delays to a minimum. I agree that this is a primary goal. However,
  as I noted at IETF 90, I think the draft should also include a secondary
  requirement to keep delay variation (jitter) down, where possible, since
  larger delay variation needs larger receiver-side buffers to compensate,
  increasing overall latency. 

- Requirement 1B states that the algorithm should react "quickly" to any
  reduction in bandwidth or increase in delay. The draft needs to define
  what quickly means in this context, since the expected timing could be
  different to other congestion control algorithms. Is the expectation 
  that the response occurs with an RTT, or with next video frame, GoP, or
  talkspurt? This comment also applies to requirements 1C, 1E, 1F, and 4.

- Requirement 1B uses an "increase in bottleneck delay" as a congestion
  signal, but it's not clear how the congestion control can distinguish an
  increase in delay at the bottleneck from an increase in delay elsewhere.
  Perhaps this should be “an increase in observed delay”?

- Requirement 1C requires the congestion controller to react to interface
  changes. Does this apply to changes in the local interface only, or to 
  changes in either the local or remote interface? One is a local matter,
  while the other requires signalling, so the distinction may be important.

- Requirement 1D seems to describe possible behaviour of the system, but
  the requirement on the algorithm is not clear. Can you either clarify,
  or remove if there is no concrete requirement?

- Requirement 1E states that "the algorithm must not overreact". Can you
  define (even approximately) what overreacting means in this context?
  Without this definition, it's not clear how this requirement could be
  translated into protocol behaviour. Similarly, what is "short-term"?

- Requirement 1F states that the algorithm "must avoid too much delay 
  buildup during those bursts". This is, at least partly, outside the 
  control of the algorithm, since it depends on the behaviour of the
  cross traffic. Perhaps the requirement ought to be that the algorithm 
  does not significantly increase the delay buildup during the bursts?

- Requirement 2 states that flows should get "roughly equal" shares of
  bandwidth, but gives no definition of “roughly equal". I realise that 
  this is a difficult issue, but some guidance, however approximate, would
  be helpful. 

- Requirement 2A is written in terms of "a useful share" of bandwidth.
  Again, defining "useful" would help: perhaps for the flow to ramp up to 
  a bandwidth that allows it to support a minimal quality media stream?

- Requirement 3A is unclear. Is the intent that there is no requirement
  that the algorithm compete equally with TCP flows that have different
  RTT?

- Requirement 3B is unclear. Is the requirement that "the congestion
  control should prioritise achieving a useful (as defined in Requirement
  2A) share of the bandwidth over achieving as low as possible transit
  delay, when these two requirements are in conflict"?
 
- Requirements 4A, 4B, and 4C seem to describe possible behaviours of the
  system, but the actual requirements are unclear. Requirment 4A could be
  that the algorithm must reach a useful sending rate for audio calls fast
  enough that the initial "Hello" is not clipped; it's not clear how this
  applies to other media. 

- Requirement 5 is for "stable" behaviour, but it is not clear what
  stability means with discontinuous transmission, since the media will
  have an on-off profile that is not stable. 

- Requirement 5A lists possible behaviour for the algorithm, but it is not
  clear what requirement is being placed on an implementation. It "may
  adapt more quickly", but is it required to do so? Previous bandwidth
  estimates "may need to be aged or thrown away", but are they required
  to be?

- Requirement 6 could be interpreted as requiring general multipath
  congestion control. Is that the intent, or is the goal only to share
  information between flows between two endpoint when those flows share 
  a common bottleneck?

- Requirement 6C gives a possible use for information, but it's not clear
  what requirement is being placed on implementations.

- Requirement 8 talks about mechanisms, using RTCP feedback and/or header
  extensions. It's appropriate that this draft gives give general feedback
  requirements, but I don't think it should be making explicit requirements
  on how RTCP or RTP header extensions are used without justification, 
  especially since the RMCAT working group has a milestone to produce a
  draft giving such recommendations. I suggest keeping requirement 8E,
  but removing the rest of requirement 8.

I also noted some editorial issues:

- The RMCAT working group should have a limited lifetime. Accordingly, 
  the title might be better written as "Congestion Control Requirements
  for Interactive Real-time Media Transport”?

- The 4th paragraph of Section 1 talks about "requirements for RMCAT" and
  "The RMCAT congestion control algorithm". I suggest these be changed to
  "requirements for congestion control of interactive real-time media" and
  "A congestion control algorithm for interactive real-time media".

- The last paragraph of Section 1 states that terminology from the WebRTC
  overview is used. This is appropriate. It might also be appropriate to
  align with draft-ietf-avtext-rtp-grouping-taxonomy and cite that draft.

- Requirement 1E talks about "short-term bursts (such as web-browsing)".
  This would be clearer if written "short-term bursts of competing traffic
  (such as web browsing)", since the bursts are not due to the congestion
  control algorithm.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 Aug 2014 19:16:20 -0400

I'll preface my remarks with a paraphrase of the US Supreme Court:  In 
many cases, I know something is X when I see it, but it's hard to put a 
written "X is <foo>" down, or the parameters of <foo> are fuzzy and 
multidimensional.  In the end, the proposals will be evaluated by humans 
looking at all the data people can provide, turning it over in their 
heads, arguing, and saying "X is best" or "Y is best for XYZ usage, and 
Z is best for ABC usage".   Kinda like "fairness"....

That said, I'll dive in:

> Apologies for the late response, but I have some extensive comments on this

Thanks for looking at it closely.

>    increasing overall latency.

How about:
           <t>Jitter (variation in the bitrate over short timescales)
           also is relevant, though moderate amounts of jitter will be
           absorbed by receiver jitter buffers.  Transit delay should be 
considered
           to include the short-term maximums of delay including jitter.</t>

>    talkspurt? This comment also applies to requirements 1C, 1E, 1F, and 4.

I'm loathe to give a hard number here, and instead leave that to the 
evaluation, since as with all things like this it's a tradeoff.  I could 
state that "quickly" means a timescale on the order of RTT times (i.e. 
O(RTT)), and certainly well sub-second.  (IMHO, a congestion mechanism 
needs to adapt down ASAP to avoid delay buildup it will then have to 
drain out).

>    Perhaps this should be “an increase in observed delay”?

Sure.

>    while the other requires signalling, so the distinction may be important.

I would say local interface changes should be noticed and both 
directions should take this into account if possible (for example as a 
sender by restarting adaptation from a known startpoint, or increase 
sensitivity/adaptation-rate temporarily in combination with an immediate 
drop in send rate as a precaution).  On the receive side, it can 
indicate an interface change via RTCP, or just let the other side adapt 
if the bottleneck has changed.  (Indicating a change may be preferable 
in order to more-intelligently adapt, but may not be required, and might 
not even help or help much.)

Really I'm interested to see what the proposals find are the best way to 
handle this problem, without constricting the solution space.

Suggested wording changes?

>    or remove if there is no concrete requirement?
Old:
           <t>The offered load may be less than the available bandwidth
           at any given moment, and may vary dramatically over time,
           including dropping to no load and then resuming a high load,
           such as in a mute operation.  The reaction time between a
           change in the bandwidth available from the algorithm and a
           change in the offered load is variable, and may be different
           when increasing versus decreasing.</t>

Proposal:
           <t>The algorithm must deal with offered loads that are less 
than the available bandwidth
           at any given moment, and may vary dramatically over time,
           including dropping to no load and then resuming a high load,
           such as in a mute/unmute operation.  Note that the reaction 
time between a
           change in the bandwidth available from the algorithm and a
           change in the offered load is variable, and may be different
           when increasing versus decreasing.</t>

i.e. make it into a requirement for the algorithm to deal with Mute 
operations and that offered load will not change immediately in response 
to the algorithm's idea of bandwidth (which was what was intended here).

>    translated into protocol behaviour. Similarly, what is "short-term"?

"the algorithm must deal with traffic bursts caused by actions such as 
webpage loading [by an aggressive browser/website combination]"?   (with 
the part in [] being perhaps removable). Again, the definition of 
"quickly" comes into play.

>    does not significantly increase the delay buildup during the bursts?

Perhaps that's a good rewording; that's a tough/painful case since they 
may smoke your router's buffers regardless of what you do, so you may 
want to keep sending at a "normal" rate or close once the algorithm 
realizes it's lost the battle (temporarily).

>    this is a difficult issue, but some guidance, however approximate, would

This is "fair" of course.   I'm not sure how I can say much more without 
constraining the solution-space artificially.  And it's worse because 
it's not a single-point measurement; defining it in detail would require 
looking at startup ramp, steady-state, reaction to BW changes and 
cross-traffic (does it remain "roughly equal"), etc.  Down this road 
lives insanity...

I can try alternate wiggle-words, or some additional somewhat-vague phrases.

>    a bandwidth that allows it to support a minimal quality media stream?

A "minimal quality media stream" may be 8Kbps (or less!) or it might be 
8Mbps, so that makes it hard to define here....

>    that the algorithm compete equally with TCP flows that have different

3A says "don't be a hog" (likely not a problem anyways, but since once 
an algorithm has "given up" on low delay due to TCP competition you 
don't want it to starve the TCP streams by going CBR for example.)  And 
for long-lived flows, it can't compete equally even with flows with the 
same RTT.

>    delay, when these two requirements are in conflict"?

That might be a nice way to state that, thanks.

>    enough that the initial "Hello" is not clipped; it's not clear how this

Those were to push the solutions in the direction of having a reasonable 
start-of-call/stream behavior, which otherwise might get ignored and not 
looked at or optimized for.  I agree they're somewhat editorial.

>    have an on-off profile that is not stable.

"must deal with"?

>    estimates "may need to be aged or thrown away", but are they required

<t>After stream resumption, the algorithm should attempt to regain a 
share of bandwidth as quickly as possible.</t>
("useful share"?)  *ducks*

>    information between flows between two endpoint when those flows share

The latter.  I thought it was clear; wording suggestions?

>    what requirement is being placed on implementations.

Right, it's editorial reminding them they can do that.

>    but removing the rest of requirement 8.

Ok.

>    for Interactive Real-time Media Transport”?

Sure

>    "A congestion control algorithm for interactive real-time media".

Sure

>    align with draft-ietf-avtext-rtp-grouping-taxonomy and cite that draft.

I think we can do that...  (I'll see how much editing it needs to do so)

>    (such as web browsing)", since the bursts are not due to the congestion

Sure.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Aug 2014 13:14:25 +0100

Thanks - responses inline.

Cheers,
Colin

On 20 Aug 2014, at 00:16, Randell Jesup <[email-masked]> wrote:
> I'll preface my remarks with a paraphrase of the US Supreme Court:  In many cases, I know something is X when I see it, but it's hard to put a written "X is <foo>" down, or the parameters of <foo> are fuzzy and multidimensional.  In the end, the proposals will be evaluated by humans looking at all the data people can provide, turning it over in their heads, arguing, and saying "X is best" or "Y is best for XYZ usage, and Z is best for ABC usage".   Kinda like “fairness"....

A lot of these are difficult to be precise about, I agree.

>          absorbed by receiver jitter buffers.  Transit delay should be considered

Sure.

> I'm loathe to give a hard number here, and instead leave that to the evaluation, since as with all things like this it's a tradeoff.  I could state that "quickly" means a timescale on the order of RTT times (i.e. O(RTT)), and certainly well sub-second.  (IMHO, a congestion mechanism needs to adapt down ASAP to avoid delay buildup it will then have to drain out).

I agree that we don’t want to give a hard number, but I think some guidelines to set expectations would be useful. React within some small multiple of the RTT would seem appropriate, possibly with some wording about possible codec constraints also (e.g., react on the next video frame, or maybe at the start of the next talk spurt)? Agree that sub-second reaction is desirable. 

Saying “In this memo, a ‘quick’ reaction to congestion means…” would then cover the later uses of the term.

> I would say local interface changes should be noticed and both directions should take this into account if possible (for example as a sender by restarting adaptation from a known startpoint, or increase sensitivity/adaptation-rate temporarily in combination with an immediate drop in send rate as a precaution).  On the receive side, it can indicate an interface change via RTCP, or just let the other side adapt if the bottleneck has changed.  (Indicating a change may be preferable in order to more-intelligently adapt, but may not be required, and might not even help or help much.)
> 
> Really I’m interested to see what the proposals find are the best way to handle this problem, without constricting the solution space.

Agree, and agree that those are likely mechanisms for doing this. 

> Suggested wording changes?

Maybe something like “It should detect handover between different interfaces (e.g., Wi-Fi to 3G) at sender or receiver, and signal these to the congestion control algorithm where possible, to help the algorithm respond quickly to such path changes”? 

>          <t>The algorithm must deal with offered loads that are less than the available bandwidth
>          such as in a mute/unmute operation.  Note that the reaction time between a
> i.e. make it into a requirement for the algorithm to deal with Mute operations and that offered load will not change immediately in response to the algorithm’s idea of bandwidth (which was what was intended here).

Sure, makes sense.

> "the algorithm must deal with traffic bursts caused by actions such as webpage loading [by an aggressive browser/website combination]"?   (with the part in [] being perhaps removable). Again, the definition of “quickly" comes into play.

Perhaps “Short-term bursts of competing traffic (e.g., due to local web browser use) can saturate a local bottleneck link, but also clear quickly. The algorithm needs to be able respond quickly to such events to help prevent queue build-up; it is desirable if it can also quickly recover its sending rate when they conclude”? 

> Perhaps that’s a good rewording; that's a tough/painful case since they may smoke your router's buffers regardless of what you do, so you may want to keep sending at a "normal" rate or close once the algorithm realizes it's lost the battle (temporarily).

Sure, it’s difficult. If it’s a transient burst that fills the queue for a short time then disappears, then you want to back off to avoid making the situation worse, then continue, but if the competing traffic is determined to keep the queue full, you’re better keeping sending and accepting the latency, and let the user hang-up if it gets too bad.

> This is "fair" of course.   I'm not sure how I can say much more without constraining the solution-space artificially.  And it's worse because it's not a single-point measurement; defining it in detail would require looking at startup ramp, steady-state, reaction to BW changes and cross-traffic (does it remain "roughly equal"), etc.  Down this road lives insanity…

Of course.

> I can try alternate wiggle-words, or some additional somewhat-vague phrases.

Add a “It is difficult to give a definition of ‘roughly equal’ because…” to make it clear why the definition is imprecise? I’m less concerned that the definitions are vague, than that they’re vague without explanation of the factors that affect them.

> A "minimal quality media stream" may be 8Kbps (or less!) or it might be 8Mbps, so that makes it hard to define here….

True, but the issue ought to be discussed. Quickly ramping up to get a useful VoIP flow is straight-forward (as you say, 8kbps), but it’s a much harder problem for higher rate media. This draft should be setting expectations that the ramp-up will take longer the higher your useful rate, and that doesn’t come across now.

> 3A says "don't be a hog" (likely not a problem anyways, but since once an algorithm has "given up" on low delay due to TCP competition you don't want it to starve the TCP streams by going CBR for example.)  And for long-lived flows, it can’t compete equally even with flows with the same RTT.

I got that from 3, but don’t see how 3A adds to it. I’d possibly suggest removing 3A, since I think it’s covered elsewhere in 2.

> Those were to push the solutions in the direction of having a reasonable start-of-call/stream behavior, which otherwise might get ignored and not looked at or optimized for.  I agree they’re somewhat editorial.

Pushing solutions in that direction makes sense, but to fit the way this draft is structured as a set of requirements, I think these need to be rephrased.

> “must deal with"?

Maybe, although might be better to just merge with 5A.

> <t>After stream resumption, the algorithm should attempt to regain a share of bandwidth as quickly as possible.</t>

“After stream resumption, the algorithm should attempt to rapidly regain its previous share of the bandwidth; the aggressiveness with which this is done will decay with the length of the pause”??

> The latter.  I thought it was clear; wording suggestions?

“across multiple RTP streams sent between two endpoints, when those RTP streams share a common bottleneck, whether or not those streams are multiplexed onto the same ports”?

> Right, it’s editorial reminding them they can do that.

Sure, but it’s in the requirements section, so needs to be phrased as such. Suggest changing “it should be possible for the application to control” to “the algorithm should allow the application to control”

-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Mon, 25 Aug 2014 23:40:34 -0400

> Saying “In this memo, a ‘quick’ reaction to congestion means…” would then cover the later uses of the term.

Ok, I'll do that.

> Maybe something like “It should detect handover between different interfaces (e.g., Wi-Fi to 3G) at sender or receiver, and signal these to the congestion control algorithm where possible, to help…

Ok, I'll come up with something like that.

> Perhaps “Short-term bursts of competing traffic (e.g., due to local web browser use) can saturate a local bottleneck link, but also clear quickly. The algorithm needs to be able respond quickly to…

That sounds pretty good, thanks

> Sure, it’s difficult. If it’s a transient burst that fills the queue for a short time then disappears, then you want to back off to avoid making the situation worse, then continue, but if the compe…

Right.  Maybe I'll combine your original and some of that.

> Add a “It is difficult to give a definition of ‘roughly equal’ because…” to make it clear why the definition is imprecise? I’m less concerned that the definitions are vague, than that they’re vague…

Sure, sounds good.

> True, but the issue ought to be discussed. Quickly ramping up to get a useful VoIP flow is straight-forward (as you say, 8kbps), but it’s a much harder problem for higher rate media. This draft sho…

Ok, how about "a useful share of the bandwidth" and "A useful share will 
depend on the media types involved and total bandwidth available, but 
should allow reasonable communication quickly assuming similar media 
types and required bandwidths".  Also, it's more about the existing 
flows ramping down fast enough so that the new flow (which will likely 
start at a "reasonable minimum" bandwidth) doesn't cause all the flows 
to start seeing delay and/or loss.  Likely applications using this will 
lower-limit the bandwidth and when forced down there will live with 
extra delay (i.e. the compete with greedy TCP case), and if delay is 
egregious or if loss builds up badly as well then it may decide to drop 
that stream or indicate connection failure.

> I got that from 3, but don’t see how 3A adds to it. I’d possibly suggest removing 3A, since I think it’s covered elsewhere in 2.

ok

> Pushing solutions in that direction makes sense, but to fit the way this draft is structured as a set of requirements, I think these need to be rephrased.

I'll take a shot at that.

> “After stream resumption, the algorithm should attempt to rapidly regain its previous share of the bandwidth; the aggressiveness with which this is done will decay with the length of the pause”??

That's better.  (I'd say "may decay" or "should decay" to avoid 
hard-restricting the solutions).

> “across multiple RTP streams sent between two endpoints, when those RTP streams share a common bottleneck, whether or not those streams are multiplexed onto the same ports”?

ok

> Sure, but it’s in the requirements section, so needs to be phrased as such. Suggest changing “it should be possible for the application to control” to “the algorithm should allow the application to…

ok

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 Aug 2014 10:48:00 +0100

Hi Randell,

That all sounds good - thanks!

Colin

On 26 Aug 2014, at 04:40, Randell Jesup <[email-masked]> wrote:
> Ok, how about "a useful share of the bandwidth" and "A useful share will depend on the media types involved and total bandwidth available, but should allow reasonable communication quickly assuming similar media types and required bandwidths".  Also, it's more about the existing flows ramping down fast enough so that the new flow (which will likely start at a "reasonable minimum" bandwidth) doesn't cause all the flows to start seeing delay and/or loss.  Likely applications using this will lower-limit the bandwidth and when forced down there will live with extra delay (i.e. the compete with greedy TCP case), and if delay is egregious or if loss builds up badly as well then it may decide to drop that stream or indicate connection failure.
> 
> That's better.  (I'd say "may decay" or "should decay" to avoid hard-restricting the solutions).
> 
>> 

-- 
Colin Perkins
http://csperkins.org/