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/
Im 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 doesnt 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 dont 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 IDs - 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?
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
