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

[[e-mail]]

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?