David, Please see a quick answer to your questions below.
-Shahid. Sent from my iPhone On Nov 8, 2013, at 1:24 PM, "David Ros" <[email protected]> wrote: > > On 8 nov. 2013, at 10:38, Akhtar, Shahid (Shahid) > <[email protected]> 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) My text says to focus on QoE as well - meaning both network metrics and service QoE. Key services on the Internet like web browsing have been around for like 20 years - so major services are slow to change. Research does exist on translating application performance to QoE - key new example may be HAS where I have mentioned a couple of papers in my talk at ICCRG. Note that since this is a research topic, we do not need to have all the answers now. > > 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:[email protected]] >> Sent: Friday, November 08, 2013 10:27 AM >> To: Akhtar, Shahid (Shahid) >> Cc: Richard Scheffenegger; [email protected]; Naeem Khademi ([email protected]); >> Gorry Fairhurst; Wesley Eddy >> Subject: Re: IETF88 Fri 08Nov13 - 12:30 Regency B >> >> >> >> On Nov 8, 2013, at 5:56 AM, "Akhtar, Shahid (Shahid)" >> <[email protected]> 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 >> [email protected] >> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
