Re: [aqm] IETF88 Fri 08Nov13 - 12:30 Regency B - Comments on Fred's document

[David Collier-Brown <[e-mail]>]

It's written in the light of recent work that suggest that tuning is
unnecessary, but is not a proof that it will never be necessary.  If it
were, the wording would arguably be "must not" as opposed to "should not".

I think the emphasis in "especially manual", however, is inappropriate. 
I would prefer to see language that says that they should adapt to
measurable conditions themselves, and not require outside intervention
to inject information they require.  I'd then weaken it for initial
settings that are never changed, like "this is strictly for
IP-over-carrier-pigeons".

--dave


On 11/07/2013 01:21 PM, Akhtar, Shahid (Shahid) wrote:
> 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:[e-mail]_]
> Sent: Thursday, November 07, 2013 11:44 AM
> To: Akhtar, Shahid (Shahid)
> Cc: Fred Baker (fred) ([e-mail]); Naeem Khademi ([e-mail])
> 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)"
> <[e-mail]>:
>  
> > 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: [e-mail] [_mailto:[e-mail]_] On Behalf Of
> > Scheffenegger, Richard
> > Sent: Tuesday, November 05, 2013 5:02 PM
> > To: [e-mail]
> > Cc: Fred Baker (fred) ([e-mail]); Naeem Khademi
> > ([e-mail])
> > 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
> > [e-mail]
> > _https://www.ietf.org/mailman/listinfo/aqm_
> > <draft-baker-aqm-recommendation-02.doc>
>  
>
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
[e-mail]           |                      -- Mark Twain
[phone]