On 8 nov. 2013, at 10:38, Akhtar, Shahid (Shahid) <shahid.akh...@alcatel-lucent.com> wrote:
[snip] > Recommend the following text in section 4.7 > > Research should 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. Can this be said to be true for the QoE of *any* application? And, if we focus on QoE instead of network metrics, (a) what apps are we going to consider? (b) do we have easy-to-use, readily-available and accurate models for assessing QoE for all those apps? (Note, I'm not trying to contradict what you say, I just want to better understand what concrete evaluation guidelines could be given on this) Thanks, David > > Research should make suggestions on how to make good decisions on buffer > sizes with each type of AQM (e.g. 2xBDP) - explaining why or how such buffer > sizes improve end-user QoE and network health. > > Research should be done on methods or good configurations that leverage > deployed AQMs such as RED/WRED that reduce delays and prevent lockout with > typical traffic and network conditions. > > > > From: Fred Baker (fred) [mailto:f...@cisco.com] > Sent: Friday, November 08, 2013 10:27 AM > To: Akhtar, Shahid (Shahid) > Cc: Richard Scheffenegger; aqm@ietf.org; Naeem Khademi (nae...@ifi.uio.no); > Gorry Fairhurst; Wesley Eddy > Subject: Re: IETF88 Fri 08Nov13 - 12:30 Regency B > > > > On Nov 8, 2013, at 5:56 AM, "Akhtar, Shahid (Shahid)" > <shahid.akh...@alcatel-lucent.com> wrote: > >> One of the the objectives of newer AQMs being defined here should be to >> minimize tuning, but we should recognize that likely tuning or some >> configuration cannot be eliminated altogether. >> >> FB: 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. >> >> SA: You argue that "initial conditions" determine some of the parameters of >> newer AQMs (like Codel and PIE), then those same initial conditions would >> also determine some of the key parameters for RED/WRED. > > I'm simply going to point out that Van and Kathy spent quite a bit of time > and effort trying to do exactly that, and it didn't pan out. Codel is their > suggestion of a replacement that is largely auto-tuning within a specified > range of situations. > > On your other points, please suggest text, and the WG can discuss whether > they buy it. > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm ================================================================= David ROS http://www.rennes.enst-bretagne.fr/~dros/ Deadlines really start to press a week or two after they pass. -- John Perry _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
