Great, I look forward to comments on the actual text. I agree the front part needs more structure and more topics called out. i started adding that in -04 and would be pleased to add a few more subsections if we get agreement.
I'll wait until I see comments before looking at updating the text with Fred. Gorry > 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. > That would seem OK to call-out, at least to me. > 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! > OK - as long as we get agreement from the various AQM proposals, some methods rely heavily on flow isolation to achieve their wanted behaviour. > > 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. > Hmmm... that will be interesting - suggest a para or two please? > 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, yes, agree completely should be added as a subsection in section 2 - This was overlooked. > * 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, Comment on bullet 3 in Sect 2. > * large-packet lock-out problems weren't mentioned, only flow-level > lock-out. > OK - suggest a line or two of text please:-) > Perhaps as a result, there's no recommendation on avoiding > synchronisation (e.g. using randomness). > There should be. > 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 >>[email protected] >>https://www.ietf.org/mailman/listinfo/aqm > > ________________________________________________________________ > Bob Briscoe, BT > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
