Subject: [ippm] RFC 2679bis and RFC 2680bis and draft-ietf-ippm-testplan-rfc2680

From: Barry Constantine <[email-masked]>
Date: Sun, 25 May 2014 16:17:59 +0000

Hello IPPM,

I have reviewed RFC 2679bis and RFC 2680bis and draft-ietf-ippm-testplan-rfc2680.

Being in the test and measurement industry, I think standardizing these delay and loss RFCs would be very valuable to the industry.  Loss and delay are two of the key parameters that are part of a service SLA; there are varying techniques used to measure loss and delay and this leads to differing measurement results (inter-operability of test equipment is a whole other story...).

I do have some comments I would like to add for each RFC and am listing these below:

RFC 2679bis:

Section 1:

Packet transfer on Faster-Than-Light (FTL) networks could result in negative delays and packet reordering, and both are covered as possibilities in the current text.

** This is interesting, can this be expanded upon with a sentence or two to explain this phenomena?

Section 2.1:

Performance of an application may depend mostly on the performance in one direction.  For example, a file transfer using TCP may depend more on the performance in the direction that data flows, rather than the direction in which acknowledgements travel.

** There were some recent comments on this, mine may overlap.  I understand how one way performance of TCP is affected by loss in the direction of the data (i.e. upload).  It was not intuitive why one way delay is important for TCP, since TCP stacks use RTT for it's congestion avoidance algorithms, etc.

Section 3.5:

Real delay values will be positive.  Therefore, it does not make sense to report a negative value as a real delay....

** Be good to tie this into the description of Faster-Than-Light (FTL) networks for clarity

Section 3.6:

At the Src host, select Src and Dst IP addresses, and form a test packet of Type-P with these addresses.  Any 'padding' portion of the packet needed only to make the test packet a given size should be filled with randomized bits to avoid a situation in which the measured delay is lower than it would otherwise be due to compression techniques along the path.

** I think this ties into the broader subject of WAN altering devices such as WAN Accelerators, Firewalls, IDS, etc which will certainly affect the delay.  It seems useful to add a paragraph (and diagram?) to discuss the various points in a network where delay may be measured and the potential impact of various devices.  It would be useful to suggest delay measurements with WAN acceleration ON and OFF, etc.

Section 3.7.2:

Errors or uncertainties related to Wire-time vs Host-time

** Good to mention here they NIC card and some of the offloading that occurs, the time stamps occur "before the wire" and there can be TCP segment offload, etc..  Capturing on the wire benefits, which might be mentioned here...

Section 3.8.4: Path

** Should traceroute be mentioned to obtain a static snapshot?  Even if it is static per se, in most managed networks the path will not change.

RFC 2680bis:

Section 2.7:

In addition, the instruments should be checked to ensure the that the possibility a packet arrives at the network interface, but is lost due to congestion on the interface or to other resource exhaustion (e.g., buffers) on the instrument is low.

** Does it make sense to suggest that the instruments should be calibrated running a head-head RFC 2544 test?

Section 2.8.1: UDP or TCP protocol

** This comments applies to both 2680bis and the 2680 draft test plan.  TCP is mentioned as a possible means to conduct loss and delay testing, but the RFC 2679/80 and test plan do not expand on guidelines when using TCP.  An example would be retransmissions, how do the loss statistics get measured when there are retransmits?  How do the delay metrics get measured when there are retransmits, etc.?  I'm not even sure that using TCP traffic for these measurements is feasible but understand that in some networks that have Layer 4 aware devices, that TCP may be the only way (this is related to my earlier comment regarding WAN accelerators, Firewalls, etc.)

Section 4.1:

The reference to healthy Internet paths operating at below 1% loss, is that dated (seems high)?

****

Again fully support these RFCs to become standards and hope these comments are useful.

Thank you,
Barry Constantine