Re: [bmwg] first WGLC on draft-ietf-bmwg-traffic

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
>