I strongly agree with Bob's concerns: - Congestion collapse cannot be prevented by AQM - Flow fairness is not a topic for AQM - AQM should be possible without any knowledge of particular flows. As such it is clearly a L2 mechanism (which does not mean that it cannot be applied in L3 boxes).
Of course, in technical implementations an AQM could be combined with fairness mechanisms like the fq_X proposals do. (I assume that in such combination AQM and scheduling essentially operate on the same queue or group of queues.) But for a clear understanding, what a particular AQM does, I would prefer to see the AQM algorithm in isolation. AQM should be applied to every buffer that can be overloaded and TCP is involved, i.e. where ingress rate can be higher the egress rate and no backpressure is in place. In middleboxes with ingress == egress rates this is not the case, except the processing capacity is insufficient. In my opinion AQM applies to multiplexed links, where several flows share the same transmission capacity. AQM cannot do a lot for a single flow on one link. In the capacity sharing case the effects of synchronization and burstiness of drops are strongly tied together. Removing the one also removes the other and this is the most what AQM can afford. Wolfram > -----Ursprüngliche Nachricht----- > Von: aqm [mailto:aqm-boun...@ietf.org] Im Auftrag von Bob Briscoe > Gesendet: Donnerstag, 15. Mai 2014 16:32 > An: Wesley Eddy; Fred Baker; Gorry Fairhurst > Cc: aqm@ietf.org > Betreff: Re: [aqm] last call results on draft-ietf-aqm-recommendation > > Wes, > > Thx. In case I don't get time to read, then type, I'll shoot my mouth off > anyway... > > Sorry this is a bit rushed and dismissive. That's not my intention - I'm v > supportive of the recommendations that have now been carefully and nicely > worded. I will give more detailed comments, but these are the MSBs. > > 1) My main concern: The two halves of the document seemed nearly > unrelated (at least in draft-03 and it looks like draft-04 hasn't changed > this). > The first half (Sections 1,2,&3) framed the problem as primarily about > preventing congestion collapse and preventing flow-unfairness, while the > recommendations (section 4) were about AQM. The irony of this sentence is > deliberate. > > I had few concerns about the recommendations text (section 4), which > we've all been focusing on, including me. But I hadn't realised the > introductory text was so out of kilter with the recommendations. > > Sections 1,2 and 3 seemed to focus on problems that I wouldn't even address > with AQM (from a quick scan it looks like these sections haven't changed in > this respect for draft-04): > > a) Congestion collapse: An AQM cannot prevent congestion collapse - that is > the job of congestion control and, failing that, of policing. > Even isolation (e.g. flow separation) doesn't prevent congestion collapse, > because collapse is caused by the load from new flow arrivals exceeding the > ability of the system to serve and clear load from existing flows, most likely > because many existing flows are not sufficiently responsive to congestion, so > retransmissions dominate over goodput (even if each unresponsive flow is in > an isolated silo). > Flow separation doesn't help when the problem is too many flows. > > b) Flow fairness (or user-fairness etc): this is a policy issue that needs to > be > built in a modular way, for optional addition to AQM. > Therefore an AQM must also work well without fairness mechanisms. > This conclusion was actually reached in the early sections, but it's not > carried > forward into the recommendations in section 4. > > If the conclusion is that AQM isn't intended to solve these two problems, we > need to clearly say so. Most people who need to read this will be confused, > so we shouldn't confuse them further! > > > 2) There's no statement of scope. > Can we really make all these recommendations irrespective of whether > we're talking about high stat-mux core links, low stat-mux access links, low- > stat-mux data centre links, or host buffers? Are there different > recommendations for edge links (on trust boundaries) vs interior links? Does > AQM apply at L2 as well as L3 (of course it does)? Which recommendations > are different for each layer? Does AQM apply for middleboxes (firewalls, > NATs etc) as much as for switches and routers? If not why not (only need > AQM if there can be queuing - perhaps due to processor overload)? > > To illustrate the problem, our goal should be AQM in every buffer. > But we really don't need and shouldn't have policing or isolation in every > buffer. > > 4) Because sections 1,2,3 focused heavily on the above two problems > (collapse and fairness) that can't really be addressed by AQM, these sections > also gave insufficient attention to problems that AQM does address (and > should address), E.g.: > > * synchronisation and lock-out were both described as vaguely the same > problem, > * synchronisation wasn't explained, > * lock-out wasn't explained but it was said to be vaguely to do with > synchronisation and solving it would help low capacity bursty flows, > * large-packet lock-out problems weren't mentioned, only flow-level lock- > out. > > Perhaps as a result, there's no recommendation on avoiding synchronisation > (e.g. using randomness). > > 5) I said these are the MSB's only, but allow me one nit about the Intro: > > " there is currently no consensus solution to controlling the > congestion caused by such aggressive flows; significant research and > engineering will be required before any solution will be available. > It is imperative that this work be energetically pursued, to ensure > the future stability of the Internet. > " > The draft could at least mention congestion policing and ConEx RFCs coming > out of the IETF right now (e.g. RFC6789 and draft-ietf-conex-abstract-mech, > which is with the IESG). > > > I promise I'll do a proper detailed review of the new text ASAP. > > > Bob > > At 13:13 15/05/2014, Wesley Eddy wrote: > >On 5/15/2014 5:09 AM, Bob Briscoe wrote: > > > Wes, > > > > > > I assume you also want comments on the new version. Is there a > > > deadline for comments? > > > > > >Absolutely, yes. There's no "deadline" at the moment, but it would be > >good to get any out sooner rather than later, especially if they're > >likely to need more discussion or are asking for major changes. > > > > > > > I prepared comments on the previous version, but didn't get the time > > > to type them up. So I want to try to remedy this with the new > > > version (that I haven't read yet). > > > > > >The diffs aren't huge, so many of your comments on the previous > >revision might still be valid. > > > > > >-- > >Wes Eddy > >MTI Systems > > > >_______________________________________________ > >aqm mailing list > >aqm@ietf.org > >https://www.ietf.org/mailman/listinfo/aqm > > __________________________________________________________ > ______ > Bob Briscoe, BT > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
