See comments in-line, Gorry First, is this based on teh discussion or the revised draft text in -04, where the words were chosen to try to reflect this - but carefully avoid saying you can not integrate AQM & scheduling?
> 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. > There can also questions with current algorithms about parameter settings if you implement this away from the edge whre you don't know the flow path RTT and other params - but that's something to work upon. > 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. > OK > 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 > _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
