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, [email protected] 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/ > 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 [email protected] https://www.ietf.org/mailman/listinfo/aqm
