Skip to main content

Traffic Management Benchmarking
RFC 7640

Yes

(Joel Jaeggli)

No Objection

(Alia Atlas)
(Barry Leiba)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana No Objection

Comment (2015-05-27 for -04)
Just one formatting nit:  the appendixes are out of place.

(Joel Jaeggli; former steering group member) Yes

Yes (for -04)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -04)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -04)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (for -04)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (2015-05-26 for -04)
Section 6.2.1 Queue/Scheduler Individual Tests Overview
I understand that is not finished work, but do we need to say a few words about codel and pie
http://datatracker.ietf.org/doc/draft-ietf-aqm-pie/ and http://datatracker.ietf.org/doc/draft-ietf-aqm-codel/

- More of a transport AD question:
"To this end, the stateful tests will use TCP test patterns to emulate applications."
Do we need to emulate any applications on SCTP test patterns?
Asking the transport ADs about which deployed protocols use SCTP, their answer was: WebRTC, SS7 signalling in 3gpp mobile networks.


Editorial:

- Section 1:

   Specifically, this framework defines the methods to characterize
   the capacity of the following traffic management features in network
   devices; classification, policing, queuing / scheduling, and
   traffic shaping.

Section 1.2

   This testing framework describes the tests and metrics for each of
   the following traffic management functions:
   - Policing
   - Queuing / Scheduling
   - Shaping

I would add classification to that list.

-  Section 1.2
    "Note the NDE SHOULD be used in "full pipe" delay mode."

I don't know what "full pipe" delay mode is

- OLD:
It is not within scope of this of this framework to specify
NEW:
It is not within scope of this framework to specify



- General observation. This is one of these documents where too many acronyms make it difficult to read (and I have some QoS background)
Ex: "The tests will verify that the network device can handle the CIR with CBS and the EIR with EBS
Note: I don't expect any action on this remark

- Section 6:

   Each test SHOULD compare the network device's internal statistics
   (available via command line management interface, SNMP, etc.) to the
   measured metrics defined in section 4. 

FYI. Most MIB interface/QoS counters are not updated real-time in routers. 10 sec for interface stats is common.
So no real-time monitoring is possible.

- two instances of tester*: not sure what they mean
    configure the tester* to generate a profile of emulated of an application traffic mixture

(Deborah Brungard; former steering group member) No Objection

No Objection (for -04)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -04)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-05-27 for -04)
Thanks for your work on this draft.  I just have one question that was raised in the SecDir review:

Was there any thought to how the tcpinc efforts might affect the ability to gather measurements?
http://www.ietf.org/mail-archive/web/secdir/current/msg05726.html

It doesn't have an impact on this draft yet, but could in the future.

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -04)