Hi All, I am resending the same comments I had sent in the earlier mail in e-mail format only (for ease of reading) as some may not have access to MS word.
Section 4.3 - Manual tuning The document states and implies that AQMs should not require manual tuning. In section 4.3 it states "The algorithms that the IETF recommends SHOULD NOT require operational (especially manual) configuration or tuning". I recommend to change this sentence to: "The algorithms that the IETF recommends should minimize tuning or configurations changes for specific traffic or network conditions" I would further argue that all AQMs will likely require or implicitly 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. 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. Section 4.7 - Further Research AQM impact on end-user QoE 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. Suggestion on best buffer sizes Research should make suggestions on how to configure buffer sizes with each type of AQM (e.g. 2xBDP etc) - explaining why/how such buffer sizes improve end-user QoE and network health. Best way to leverage deployed AQMs Research should be done on 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. Best regards, -Shahid. -----Original Message----- From: Scheffenegger, Richard [mailto:[email protected]] Sent: Thursday, November 07, 2013 11:44 AM To: Akhtar, Shahid (Shahid) Cc: Fred Baker (fred) ([email protected]); Naeem Khademi ([email protected]) Subject: Re: IETF88 Fri 08Nov13 - 12:30 Regency B Hi shahid, Thanks. Please note that not necessarily everyone has access to full featured ms word; a short summary of the nits sent to the list, or direct communication with the authors is the usual way. It looks that many of you comments are not so much specifica of the draft but discussion points for the wg. Repeating them on list with some context would be good! Best regards Richard Von meinem iPhone gesendet Am 07.11.2013 um 09:01 schrieb "Akhtar, Shahid (Shahid)" <[email protected]>: > 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. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Scheffenegger, Richard > Sent: Tuesday, November 05, 2013 5:02 PM > To: [email protected] > Cc: Fred Baker (fred) ([email protected]); Naeem Khademi > ([email protected]) > Subject: [aqm] IETF88 Fri 08Nov13 - 12:30 Regency B > > Hi, > > this is just a simple remainder that the WG will convene also this > Friday; > > As the mechanism update presentations took quite a bit longer than we had > expected - and we appreciate the discussion these presentations have sparked > - we agreed with Fred to have his presentation as the first agenda point on > Friday; the second agenda point will be a presentation around AQM evaluation > process and criteria. > > > The Room will be Regency B (3. Floor), and we will start at 12:30. > > > Best regards, > > Richard Scheffenegger > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > <draft-baker-aqm-recommendation-02.doc>
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
