Thanks for your review, Elwyn! I understand that the authors are working on incorporating the feedback.
Jari On 09 Feb 2015, at 20:13, Elwyn Davies <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-aqm-recommendation-09.txt > Reviewer: Elwyn Davies > Review Date: 2015/02/09 > IETF LC End Date: 2014/12/24 > IESG Telechat date: (if known) - > > Summary: Almost ready for BCP. I have done some homework on the subject of > AQM since my previous review and reread the latest version (-09). I think a > couple of my comments in the previous review were inappropriate - apologies > to the authors - and we did not come to a meeting of minds at that point. On > rereading, I think it is generally an excellent and readable document. > However there are a couple of points, including one left over from the > previous review, that could be usefully and (IMO) importantly taken into > account. > > > Minor Issues: > > Ensuring that mechanisms do not interact badly: > Given that a number of different mechanisms are being developed and > potentially may all be deployed in various quantities in routers, etc., along > the path that a packet takes, ensuring that this does not lead to instability > or other interactions should also be a target of research. A number of > applications now have flow control mechanisms that may be deployed as an > adjunct to TCP so that a single path may have multiple nested end-to-end > feedback loops (notably, just about to be standardized, HHTP2!) and it would > be very wise to ensure that adding AQM into the loop does not lead to > problems. > A short extra paragraph in s4.6 would cover the case I think. > > Interactive applications such as gaming; and > The gaming aspect is mentioned very briefly (in s4.6). Gaming is a major > application and, for many consumers, ensuring that interaction with > server-based games is low latency and pretty reliable is key to their > enjoyment and the continuation of a large segment of the computer > entertainment market. > > Combinations of traffic: > A little more stress on the need to consider combinations of traffic in > further research would be desirable. I found CableLabs report of their > simulation comparisons of the various AQM mechanisms being developed to be > instructive in various ways: general AQM background, requirements of gaming > and similar applications and thinking about combinations of traffic. > > Nits/editorial comments: > (not fixed from -08) > General: s/e.g./e.g.,/, s/i.e./i.e.,/ > > s1.2, para 2(?) - top of p4: s/and often necessary/and is often necessary/ > s1.2, para 3: s/a > class of technologies that/a class of technologies that/ > ^^^^^^ > > s2, first bullet 3: s/Large burst of packets/Large bursts of packets/ > > s2, second set of bullets, #2: Probably need to expand POP and RDP (DNS and > IMAP are in the RFC editor's "well known" class). Alternatively could change > POP/IMAP to "email access protocols". > > s3, bullet #2, last para: s/open a large numbers of short TCP flows/may open > a large number of short duration TCP flows/ > > s4, last para: s/experience occasional issues that need moderation./can > experience occasional issues that warrant mitigation./ > > s4.2, para 6, last sentence: s/similarly react/react similarly/ > > s4.2.1, para 1: s/using AQM to decider when/using AQM to decide when/ > > s4.7, para 3: >> the use of Map/Reduce applications in data centers > I think this needs a reference or a brief explanation. Maybe: > Jeffrey Dean and Sanjay Ghemawat. 2008. MapReduce. Commun. ACM 51, 1 (January > 2008), 107–113. DOI:http://dx.doi.org/10.1145/1327452.1327492 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
