Hi Snipping other stuff, I would like to add some specific points inline:
On Thu, Nov 7, 2013 at 10:45 AM, Fred Baker (fred) <[email protected]> wrote: > > On Nov 7, 2013, at 8:59 AM, "Akhtar, Shahid (Shahid)" < > [email protected]> wrote: > > >> 4. Conclusions and Recommendations > >> [snip] > >> 3. The algorithms that the IETF recommends SHOULD NOT require > >> operational (especially manual) configuration or tuning. > > > > Some tuning may be required or implicitly assumed for virtually all AQMs > – please see my comment later. > > That's an opinion. One of the objectives of Van and Kathy's work, and > separately of Rong Pan et al's work, is to design an algorithm that may > have different initial conditions drawn from a table given the interface it > finds itself on, but requires no manual tuning. The great failure of RED, > recommended in RFC 2309, is not that it doesn't work when properly > configured; it's that real humans don't have the time to properly tune it > differently for each of the thousands of link endpoints in their networks. and "Adaptive RED" was an attempt to address exactly that issue! but it seems that it has likely to have remained un-noticed since 2001. The draft on Sally's homepage still says "August 1, 2001, under submission" while it's been in Linux for a while :-). > There is no point in changing away from RED if that is also true of the > replacement. > >> 7. Research, engineering, and measurement efforts are needed > >> regarding the design of mechanisms to deal with flows that are > >> unresponsive to congestion notification or are responsive, but > >> are more aggressive than present TCP. > > > > Do we want to make a suggestion on how to configure buffer sizes > with each type of AQM here (e.g. 2xBDP etc) or simply state that research > should be conducted on the best buffer sizes to use with AQM. > > I'm not sure that buffer sizes are specific to AQM algorithms; I'd > entertain evidence otherwise. Buffer *thresholds* ("at what point do we > start dropping/marking traffic?") may differ between algorithms. Buffer > size ("how many bytes/packets do we allow into the queue in the worst > case?") is a matter of the characteristics of burst behavior in a given > network and the applications it supports. If I have, say, a Map/Reduce > application that simultaneously asks thousands of systems a question, the > queues in the intervening switches will need to be able to briefly absorb > thousands of response packets. The key word here is "briefly". When Van or > Kathy talk about "good queue" and "bad queue", they are saying that burst > behavior may call for deep queues, but we really want the steady state to > achieve 100% utilization with a statistically empty queue if we can > possibly achieve that. > The terms "good queue", "bad queue" or "briefly" are very subjective. How "brief" is the key. We can possibly know that when we're talking about a specific application in a specific environment (e.g. Map/Reduce in data center). On the access link with a mixture of all sort of traffics, and also RTTs , that's more controversial. A queue that gives a 100 ms burst a pass, is a good queue from CoDel designer's point of view (!) Cheers, Naeem
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
