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

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

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" <[e-mail]> wrote:

> 
> On 8 nov. 2013, at 10:38, Akhtar, Shahid (Shahid) <[e-mail]> 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:[e-mail]] 
>> Sent: Friday, November 08, 2013 10:27 AM
>> To: Akhtar, Shahid (Shahid)
>> Cc: Richard Scheffenegger; [e-mail]; Naeem Khademi ([e-mail]); Gorry Fairhurst; Wesley Eddy
>> Subject: Re: IETF88 Fri 08Nov13 - 12:30 Regency B
>> 
>> 
>> 
>> On Nov 8, 2013, at 5:56 AM, "Akhtar, Shahid (Shahid)" <[e-mail]> 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
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm