Re: [aqm] A few comments on draft-ietf-aqm-eval-guidelines-05

[Nicolas Kuhn <[e-mail]>]

Hi, 

Thank you for pointing out these issues. 
We just uploaded a -06 version that considers
all your points. 

Thanks a lot. 

Nicolas 

> On 30 Jun 2015, at 15:35, [e-mail] wrote:
> 
> 
> Hi authors,
> 
> I've just read -05 of the document and see much more clarity and
> precision, and that it includes most of the issues I noted. Thanks.
> 
> There are a few minor comments (see below) that I think would be good to
> address. most of these are minor, and could be handed with any other
> comments in a quick revision.
> 
> Best wishes,
> 
> Gorry
> 
> 
> ----
> 
> 
> Overall: /e.g./e.g.,/
> 
> Section 1.1:
> /in various scenarios to ensure the safety/
> I’m not sure this is quite correct, I suspect we may mean:
> /in a variety of scenarios to ensure the safety/
> 
> Section 1.2:
> /any AQM proposal must be evaluated/
> may be better as:
> /any AQM proposal needs to be evaluated/
> 
> Section 1.4:
> /AQM: there may be a debate on whether a scheduling scheme is
>     additional to an AQM algorithm or is a part of an AQM algorithm.
>     The rest of this memo refers to AQM as a dropping/marking policy
>     that does not feature a scheduling scheme./
> 
> RFC2309.bis (aka draft-ietf-aqm-recommendation) makes this recommendations
> and I think the text could be tightened by reference to this. For example:
> 
> /AQM: [draft-ietf-aqm-recommendation] separately describes the
>     AQM algorithm implemented in a router from the scheduling of
>     packets sent by the router.
>     The rest of this memo refers to the AQM as a dropping/marking policy
>     as a separate feature to any interface scheduling scheme./
> 
> 
> Section 2.5
> - This section introduces SUT and DUT, but these do not seem to be used
> elsewhere, so maybe new terms do not need to defined?
> 
> /highly RECOMMENDED/RECOMMENDED/
> - I think the IETF keyword doesn’t need another word, and it is cleaner if
> the keyword only is used.
> 
> Section 3
> /set up/setup/
> - one word.
> 
> Section 4:
> / It fills up
>  unmanaged buffers until the TCP sender receives a signal (packet
>  drop) that reduces the sending rate./
> - Strictly speaking, this is not true - it applies to a bulk flow using
> TCP, not to TCP itself.
> 
> /Not all applications using TCP use the same flavor of TCP./
> perhaps should be:
> /Not all endpoints (or applications) using TCP use the same flavor of TCP. /
> 
> 
> /to the section 2 of /to section 2 of /
> 
> 
> 6.  Burst Absorption
> - add fuel stop at end of the para.
> 
> 7.
> /The available capacity at the physical layer/
> could be better as:
> /The capacity available to the schedular/
> 
> /The scenario MAY consist of TCP NewReno flows between sender A and
>  receiver B.  /
> On reflexion, I think this is better:
> /The scenario could consist of TCP NewReno flows between sender A and
>  receiver B.  /
> (I don’t think a keyword is appropriate here.)
> 
> 10.2
> /AQM proposals SHOULD highlight parts of AQM logic/
> to / AQM proposals SHOULD highlight parts of their AQM logic/
> 
> 
> 12.  Interaction with ECN
> 
> - We should probably now add some explicit tests for compliance here, does
> this help:
> 
> Section 3 of [ECN-Benefit] describes expected operation of routers
> enabling ECN.
> 
> AQM schemes SHOULD NOT drop or remark packets solely because the ECT(0) or
> ECT(1) codepoints are used, and when ECN-capable SHOULD set a CE-mark on
> ECN-capable packets in the presence of incipient congestion. SHOULD
> implement
> 
> 12.1
> /(ECN) [RFC3168] is an alternative/
> - remove brackets around ECN.
> 
> Reference
> 
> - Please use a consistent “tag” style for ID’s - this will be preserved
> when this is published, so be careful to name the tags in a consistent
> way.
> 
> TCPEVAL2013 - Format? - Work in Progress?
> 
> Conference references: please provide place of the conference?
> 
>