Works for me - thanks for being so quick. Gorry
> 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 > _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
