Re: [aqm] IETF88 Fri 08Nov13 - 12:30 Regency B

["Akhtar, Shahid (Shahid)" <[e-mail]>]

Fred, All,

I am traveling today - so should respond by end of day.

- Shahid.

Sent from my iPhone

On Nov 7, 2013, at 10:45 AM, "Fred Baker (fred)" <[e-mail]> wrote:

> 
> On Nov 7, 2013, at 8:59 AM, "Akhtar, Shahid (Shahid)" <[e-mail]> 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.
> 
>>>   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.
> 
>>> 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.
> 
>>> 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.