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

From: Zaheduzzaman Sarker <[email-masked]>
Date: Wed, 12 Nov 2014 08:45:10 +0000

Hi,

A new version of draft-ietf-rmcat-cc-requirements has been uploaded addressing the comments so far we have received. http://www.ietf.org/internet-drafts/draft-ietf-rmcat-cc-requirements-08.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-cc-requirements-08

BR

Zahed
> -----Original Message-----
> From: rmcat [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: den 26 augusti 2014 11:48
> To: Randell Jesup
> Cc: [email-masked]
> Subject: Re: [rmcat] Last Call: <draft-ietf-rmcat-cc-requirements-05.txt>
> (Congestion Control Requirements For RMCAT) to Informational RFC
> 
> Hi Randell,
> 
> That all sounds good - thanks!
> 
> Colin
> 
> 
> On 26 Aug 2014, at 04:40, Randell Jesup <[email-masked]> wrote:
> > On 8/20/2014 8:14 AM, Colin Perkins wrote:
> >>
> >>>> - 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.
> >>> 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.
> >
> > Ok, I'll do that.
> >
> >>
> >>>> - 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"?
> >>> Sure.
> >>>
> >>>> - 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.
> >>> 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"?
> >
> > Ok, I'll come up with something like that.
> >
> >>
> >>>> - 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"?
> >>> "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"?
> >
> > That sounds pretty good, thanks
> >
> >>
> >>>> - 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?
> >>> 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.
> >
> > Right.  Maybe I'll combine your original and some of that.
> >
> >>
> >>>> - 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.
> >>> 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.
> >
> > Sure, sounds good.
> >
> >>
> >>>> - 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?
> >>> 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.
> >
> > 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.
> >
> >>>> - Requirement 3A is unclear. Is the intent that there is no requirement
> >>>>   that the algorithm compete equally with TCP flows that have different
> >>>>   RTT?
> >>> 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.
> >
> > ok
> >
> >>
> >>>> - 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.
> >>> 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.
> >
> > I'll take a shot at that.
> >
> >>
> >>>> - 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.
> >>> "must deal with"?
> >> Maybe, although might be better to just merge with 5A.
> >>
> >>>> - 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?
> >>> <t>After stream resumption, the algorithm should attempt to regain a
> >>> share of bandwidth as quickly as possible.</t> ("useful share"?)
> >>> *ducks*
> >> "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).
> >
> >>
> >>>> - 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?
> >>> 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"?
> >
> > ok
> >
> >>
> >>>> - Requirement 6C gives a possible use for information, but it's not clear
> >>>>   what requirement is being placed on implementations.
> >>> 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"
> >
> > ok
> >
> >
> > --
> > Randell Jesup -- rjesup a t mozilla d o t com
> >
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
>