Gorry - I added a few words to add to those from Fred, see in-line as [gf].
> > On Nov 7, 2013, at 8:59 AM, "Akhtar, Shahid (Shahid)" > <[email protected]> wrote: > >> Hi All, >> >> Had some comments on Fred's document. I have added the comments as track >> changes in a word document to easily see them. I used the 02 version. >> >> Thanks. > > > Permit me to put your comments in email, along with my own views. Also > adding my co-author and the other working group chair on the CC line; if > he is like me, he receives far too much email, and mail that is explicitly > to or copies him bubbles higher in the column. > >>> 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. > There is no point in changing away from RED if that is also true of the > replacement. > [gf] I note you commented on the previous individual submission. In the latest version (WG -00 revision), we tried to clarify the difference between the overall goal and practicalities. Do you think the update accommodate the need/ability for tuning to specific use-cases? >>> 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. > [gf] I would love to be able start making recommendations in this space, but I think this is a lot more complicated. But, "buffer size" in actual router/middlebox design isn't just a single number, there are multiple buffers, thresholds and scheduling that interplay and relate to specific methods. I think this particular draft, as a BCP, should not delve into detail here. >>> 4.3. AQM algorithms deployed SHOULD NOT require operational tuning >>> >>> A number of algorithms have been proposed. Many require some form >>> of >>> tuning or initial condition. This can make them difficult to use >>> operationally. Hence, self-tuning algorithms are to be preferred. >>> The algorithms that the IETF recommends SHOULD NOT require >>> operational (especially manual) configuration or tuning. >> >> May be better to state that tuning should be minimized. For the second >> sentence The algorithms that the IETF recommends should minimize tuning >> or configurations changes for specific traffic or network conditions >> >> I would argue that all AQMs will likely require or assume some type of >> configuration/tuning. >> >> For example, if we take Codel: >> >> · For small thin links, such as 1-10Mbs DSL, the 5ms target would >> increase packet loss significantly and at 2Mbps, a single MTU time may >> even exceed the 5ms target. >> >> · If the average RTT of all flows going through a link is more >> than 500ms, e.g. for satellite, then the 100ms interval would >> prematurely drop packets before the sources have had a chance to reduce >> their sending rate. Or if the average RTT is very low e.g. 10ms such >> as for flows between data-center elements, then 100ms interval may be >> slow to signal congestion back to the sources and significant packet >> loss may have occurred before such signaling. > > > What you describe is what I referred to as "initial conditions derived > from the links the algorithm finds itself on". We may be in violent > agreement there. If so, the wording I might suggest would be "SHOULD NOT > require operational (especially manual) configuration or tuning apart from > automated determination of initial conditions" or some such thing. > [gf] Again, is the WG -00 draft closer or not to what you are thinking? >>> 4.7. The need for further research >>> >>> The second recommendation of [RFC2309] called for further research >>> in >>> the interaction between network queues and host applications, and >>> the >>> means of signaling between them. This research has occurred, and we >>> as a community have learned a lot. However, we are not done. >>> >>> We have learned that the problems of congestion, latency and buffer- >>> sizing have not gone away, and are becoming more important to many >>> users. A number of self-tuning AQM algorithms have be found that >>> offer significant advantages for deployed networks. There is also >>> renewed interest in deploying AQM and the potential of ECN. >>> >>> An obvious example of further research in 2013 is the need to >>> consider the use of Map/Reduce applications in data centers; do we >>> need to extend our taxonomy of TCP/SCTP sessions to include not only >>> "mice" and "elephants", but "lemmings"? "Lemmings" are flash crowds >>> of "mice" that the network inadvertently tries to signal to as if >>> they were elephant flows, resulting in head of line blocking in data >>> center applications. >> >> Such research should also focus on improving end user QoE from AQMs >> rather than network related metrics only. Often a significant change in >> a network metric may only make a minimal change in end-user QoE and thus >> the value of such change may be minimal. > > > There is also a question of what user is under discussion. If you take a > look at http://www.ietf.org/proceedings/88/slides/slides-88-aqm-0.pptx and > specifically the third slide, you will see (and tomorrow afternoon I will > discuss) a capture I took of pings from my home network to another site > overnight. In the evening, we watched a movie (home network), and in the > morning I had a video conference (office network). I'll tell you right now > that both worked fine, and managing the delay to zero or allowing it to be > one hundred ms would not have materially affected the QOE of either. > However, my ping is a competing application, and it saw sustained increase > in delay, variation in delay, and the possibility of loss as a result of > the queuing. The value of AQM is in part to the application being > throttled, but in large part to competing applications, and the QOE of > both must be considered. > >>> Examples of other required research include: >>> >>> o Research into new AQM and scheduling algorithms. >>> >>> o Research into the use of and deployment of ECN alongside AQM. >>> >>> o Tools for enabling AQM (and ECN) deployment and measuring the >>> performance. >>> >>> o Methods for mitigating the impact of non-conformant and malicious >>> flows. >> >> Methods or configurations that leverage deployed AQMs such as RED/WRED >> to reduce delays and lockout for typical traffic which require minimal >> effort or tuning from the operator. > > Not a complete sentence, but I think I understand what you're getting at. > You would like to have research determine how to easily configure existing > systems using the tools at hand. I'm all for it in the near term. > [gf] Gorry _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
