I think that it is a good plan to expect a separate draft on more advanced techniques.
However, AQM has been deployed in places (and likely more so), so what I was hoping was that this particular draft could scope itself carefully to state the constraints of the tests. I don't think it is wise simply to ignore the AQM-related issues, although this scoped could well be addressed in the start and end of the document. I agree the details of AQM tests and QoS-based tests are likely to be more complicated and best declared out of scope. Gorry > Hi Gorry, > > Many thanks for your detailed comments. > > The goal of this draft is to describe the commonly used traffic management > techniques in switches and routers. AQM (RED, WRED etc.) is an advanced > traffic management technique which we plan on addressing in a separate > draft. Tail drop is the commonly used technique in switches and routers > for addressing congestion control. Please see references to Cisco and > Brocade configuration guides - > (http://www.cisco.com/c/en/us/td/docs/routers/10000/10008/configuration/guides/qos/qoscf/10qqueue.html#wp1041728; > http://www.brocade.com/downloads/documents/product_manuals/B_NetIron/NetIronUnified_05400a_ConfigGuide.pdf). > > BTW, David asked us at the last IETF meeting about AQM and the above > response was well received by the working group. > > We will address all your non AQM comments in the next version of the > draft. > > Thanks, > Ramki > > -----Original Message----- > From: bmwg [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Thursday, September 25, 2014 12:33 AM > To: [email protected]; MORTON, ALFRED C (AL) > Cc: [email protected] > Subject: Re: [bmwg] [aqm] first WGLC on draft-ietf-bmwg-traffic > > > I have a few comments from a quick pass through this document. I think it > is useful to define such tests, and I suspect those performing the tests > may understand the wider context of testing a specific mechanism, but I > have a concern that the tests would produce strange results if deployed > with sophisticated traffic management, and this is not really discussed. I > think this needs to be addressed, and if necessary the cope of the tests > clearly stated. > > I am worried that while the tests may help characterise a single > shaper/policer, there is a need to extend the document at least to comment > on more complex interactions that can occur. > > QoS Frameworks define policies (e.g. DS) that can map DSCPs (or MF > classified traffic) to treatments, possibly aggregating behaviours for > different traffic aggregates. Treatments are not independent - traffic > with one marking can and does traffic with a different marking (well its > intended to). Testing multiple DSCPs in DS at the same time is more > complex, it should not be assumed that each of these can be characterised > separately. > > AQM seeks to manage buffering, and this reaction is likely to be triggered > by test sequences. When triggered, the response (loss, delay) can impact > the flow's treatment long after the traffic burst that triggered AQM in > the first place. > > Many AQM methods are also used in combination with scheduling, again this > can be and often is non-trivial and depends on the number of flows and > sometimes the hashing of the flows to queues, etc within the scheduling > framework. > > Other specific comments follow. > > Gorry > > --- > > Section 1: > Introduction needs to define terms when first used. > - would be good to define VLAN and DSCP > > > /sent onto to the next network/sent to the next network/ > - is it also possible to say "forwarded" rather than "sent"? > > Active Queue Management (AQM): > - would be good to cite: > https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ > > Please define MEF > > /of it's egress ports/of its egress ports/ > > /The Network Delay Emulator (NDE) is a requirement for the TCP > stateful tests/ > - probably true of any control-loop based congestion control (i.e. TCP is > an example, SCTP, DCCP and other congestion controls layered on UDP would > also need this (including some uses of RTP). > > Please define BDPs > > Section 3: > > /Another goal is to devise methods that utilize flows with > congestion-aware transport (TCP) / > - I think TCP is an example here, and needs an e.g., to avoid it seeming > like this is the only test case. Note also this comment applies later in > the same para. > > When it comes to an active technique, the concept of Burst Size Achieved > (BSA) and Lost packets (LP) is less clear, since won't this also depend > on the recent history of the flow traffic patterns and could be > significantly influenced by scheduling mechanisms between flows (i.e. > whether the flow is hashed to a separate queue, whether the flow is > classified as "new" or "old" and the total number of flows being > serviced). Performance could be quite different for a single flow test. > > With Active management, Packet Delay (PD) also becomes a function of > traffic. > > Section 4.2 - I think the document should mention the need to test for > other non TCP congestion-controlled traffic, although I could see that for > simplicity the tests are defined only for TCP. > > 5.1.1 Burst Hunt with Stateless Traffic > - A cautionary note here could be helpful, that advises that if AQM is > used, the bursts must be sufficiently separated in time that they do not > cumulatively trigger a response - since AQM algorithms can have history, > treatment of a subsequent burst can be influenced by an earlier burst. > > 5.2.1. and 6.4: > - could note that multiple flows may also be queued and scheduled > separately within the device. > > Informative References > -missing > > >> BMWG (and AQM): >> >> A WG Last Call period for the Internet-Draft on Traffic Management >> Benchmarking: >> >> http://tools.ietf.org/html/draft-ietf-bmwg-traffic-management >> >> will be open from 23 September 2014 through October 21 2014. >> >> These drafts are beginning the BMWG Last Call Process. See >> http://www1.ietf.org/mail-archive/web/bmwg/current/msg00846.html >> >> which says: >> ... >> The primary change is a requirement that approximately four WG members >> complete a review template for the draft (or set of drafts), upon >> entry to the Last Call Process. The WG reviewers should be outside the >> body of active contributors (editors + authors). >> The goal is to produce a quality review with valuable feedback on the >> draft(s), and not to set a minimum number of people willing to >> complete the review template. Directed feedback, regardless of >> quantity, is a better condition by which BMWG can more clearly assess >> a draft's readiness to advance. >> (the template is appended to the archived message) >> >> Please read and express your opinion on whether or not these >> Internet-Drafts should be forwarded to the Area Directors for >> publication as Informational RFCs. Send your comments to this list or >> [email protected] and [email protected] >> >> Al >> bmwg co-chair >> >> _______________________________________________ >> aqm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/aqm >> > > _______________________________________________ > bmwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bmwg > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
