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:rmcat-bounces@xxxxxxxx] On Behalf Of Colin Perkins > Sent: den 26 augusti 2014 11:48 > To: Randell Jesup > Cc: rmcat@xxxxxxxx > 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 <randell-ietf@xxxxxxxxx> 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/ > >