Re: Third WGLC on draft-ietf-bmwg-traffic-management
Barry Constantine <[email protected]>
| Newsgroups | gmane.ietf.bmwg |
|---|---|
| Message-ID | <[email protected]> |
Hi Al, Thanks for the comments, one question in this area (see my initials BAC): ACM: The first sentence for SR should give the definition, let's qualify it later. OLD - Shaper Rate (SR): the Shaper Rate is only applicable to the traffic shaping tests. The SR represents the average egress output rate (bps) over the test interval. NEW - Shaper Rate (SR): The SR represents the average DUT output rate (bps) over the test interval. The Shaper Rate is only applicable to the traffic shaping tests. ACM: Need the same fixes in SBB and SBI below, also s/shall/SHALL/ Also "(bytes back to back)" must respect the BAC: What did you mean by ,,, / Also "(bytes back to back)" must respect the...??? - Shaper Burst Bytes (SBB): the Shaper Burst Bytes is only applicable to the traffic shaping tests. A traffic shaper will emit packets in different size "trains" (bytes back-to-back). This metric characterizes the method by which the shaper emits traffic. Some shapers transmit larger bursts per interval, and a burst of 1 packet would apply to the extreme case of a shaper sending a CBR stream of single packets. This metric shall be reported in units of bytes, KBytes, or MBytes. Thank you, Barry Constantine JDSU Network and Service Enablement Principal Member Technical Staff 301-325-7069 -----Original Message----- From: bmwg [mailto:[email protected]] On Behalf Of MORTON, ALFRED C (AL) Sent: Monday, February 16, 2015 6:28 PM To: [email protected] Subject: Re: [bmwg] Third WGLC on draft-ietf-bmwg-traffic-management Hi Barry and Ramki, This is getting closer, comments and suggestions below. (you'll have to text search for locations, sorry) Al (as a participant) BMWG: The WGLC ends on the 19th. Al (as co-chair) -=-=-=-=-=-=- Global: Decide how you want to call-out references, but the text in Brackets must be present: use RFC 1242 [RFC1242] defines... or [RFC1242] defines... -=-=-=-=-=-=-=- - Lost Packets(LP): For all traffic management tests, the tester will transmit the test packets into the DUT ingress port and the number of packets received at the egress port will be measured. The difference between packets transmitted into the ingress port and received at the egress port is the number of lost packets as measured at the egress port. These packets must have unique identifiers such that only the test packets are measured. For cases where multiple flows are transmitted from ingress to egress port (e.g. IP conversations), each flow must have sequence numbers within the test packets stream. ACM: I think some suggested references got confused... OLD RFC 4737 and RFC 2680 [RFC2680] describe the need to establish the time threshold to wait before a packet is declared as lost, and this threshold MUST be reported with the results. This metric shall be reported as an integer number which cannot be negative. NEW [RFC6703] and [RFC2680] describe the need to establish the time threshold to wait before a packet is declared as lost, and this threshold MUST be reported with the results. This metric shall be reported as an integer number which cannot be negative. (see: http://tools.ietf.org/html/rfc6703#section-4.1) ACM: This benchmark is a bit confusing now, I suggest to simply measure OOO: OLD - Out of Sequence (OOS): in additions to the LP metric, the test packets must be monitored for sequence and the out-of-sequence (OOS) packets. RFC 4689 defines the general function of sequence tracking, as well as definitions for in-sequence and out-of-order packets. Out-of-order packets will be counted per RFC 4737 and RFC 2680 [RFC2680]. This metric shall be reported as an integer number which cannot be negative. NEW - Out of Order (OOO): in additions to the LP metric, the test packets must be monitored for sequence. [RFC 4689] defines the general function of sequence tracking, as well as definitions for in-sequence and out-of-order packets. Out-of-order packets will be counted per [RFC 4737]. This metric shall be reported as an integer number which cannot be negative. - Packet Delay (PD): the Packet Delay metric is the difference between the timestamp of the received egress port packets and the packets transmitted into the ingress port and specified in RFC 1242 [RFC1242]. The transmitting host and receiving host time must be in time sync using NTP , GPS, etc. This metric shall be reported as an real number of seconds which cannot be negative, which usually indicates a time synchronization problem. ACM: there are too many "which"es in the last sentence. Try this: NEW time sync using NTP , GPS, etc. This metric SHALL be reported as a real number of seconds, where a negative measurement usually indicates a time synchronization problem between test devices. - Packet Delay Variation (PDV): the Packet Delay Variation metric is the variation between the timestamp of the received egress port packets and specified in RFC 5481 [RFC5481]. Note that per RFC 5481, this PDV is the variation of one-way delay across many packets in the traffic flow. Per the measurement formulat in RFC 5481, select the high percentile of 99% and units of measure will be a real number of seconds (negative is not possible for PDV and would indicate a measurement error). Constantine January 27, 2015 [Page 10] ? Internet-Draft Traffic Management Benchmarking November, 2014 ACM: The first sentence for SR should give the definition, let's qualify it later. OLD - Shaper Rate (SR): the Shaper Rate is only applicable to the traffic shaping tests. The SR represents the average egress output rate (bps) over the test interval. NEW - Shaper Rate (SR): The SR represents the average DUT output rate (bps) over the test interval. The Shaper Rate is only applicable to the traffic shaping tests. ACM: Need the same fixes in SBB and SBI below, also s/shall/SHALL/ Also "(bytes back to back)" must respect the - Shaper Burst Bytes (SBB): the Shaper Burst Bytes is only applicable to the traffic shaping tests. A traffic shaper will emit packets in different size "trains" (bytes back-to-back). This metric characterizes the method by which the shaper emits traffic. Some shapers transmit larger bursts per interval, and a burst of 1 packet would apply to the extreme case of a shaper sending a CBR stream of single packets. This metric shall be reported in units of bytes, KBytes, or MBytes. - Shaper Burst Interval(SBI): the interval is only applicable to the traffic shaping tests and again is the time between shaper emitted bursts. ACM: ... measured at the DUT output. (?) OLD ...This metric shall be reported as an real number of seconds which cannot be negative, which usually indicates a time synchronization problem. NEW ...This metric shall be reported as an real number of seconds. (note: one test device is making this measurement, right? no sync problem...) The TCP implementation used by the test host MUST be specified in the test results (e.g. TCP New Reno, TCP options supported, etc.). ACM: (the results could be worthless without it) OLD Additionally, RFC 3148 recommends that specific congestion control algorithm details that should also be included in the test results. NEW Additionally, the test results SHALL provide specific congestion control algorithm details, as per [RFC3148]. ACM: OLD Finally, application throughput measurements are based off of Layer 4 NEW Finally, application throughput measurements are based on Layer 4 EOT ________________________________________ From: bmwg [[email protected]] On Behalf Of MORTON, ALFRED C (AL) Sent: Wednesday, February 04, 2015 7:07 PM To: [email protected]; [email protected] Subject: [bmwg] Third WGLC on draft-ietf-bmwg-traffic-management 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 4 February 2015 through 19 February 2015. Please note that the RFC diff for this version indicates the introduction of many new instances of RFC 2119 Requirements Language: http://www.ietf.org/rfcdiff?url2=draft-ietf-bmwg-traffic-management-02 Past reviewers should check the current draft and indicate their current opinion or support. The second WGLC (on -01) closed on 6 January, 2015 with substantial comments and the authors believe they are now addressed. The first WGLC (on -00) closed October 21 2014, with substantial comments. This draft is continuing the BMWG Last Call Process. See http://www1.ietf.org/mail-archive/web/bmwg/current/msg00846.html Please read and express your opinion on whether or not this Internet-Draft should be forwarded to the Area Directors for publication as an Informational RFC. Send your comments to this list or [email protected] and [email protected] Al bmwg co-chair _______________________________________________ bmwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/bmwg _______________________________________________ bmwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/bmwg