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

"MORTON, ALFRED C (AL)" <acmorton@att.com> Fri, 04 July 2014 20:48 UTC

Return-Path: <acmorton@att.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907BC1B2FA1 for <ippm@ietfa.amsl.com>; Fri, 4 Jul 2014 13:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQDTixXEaUpM for <ippm@ietfa.amsl.com>; Fri, 4 Jul 2014 13:48:45 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id C91EE1B2F9F for <ippm@ietf.org>; Fri, 4 Jul 2014 13:48:44 -0700 (PDT)
Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 056F5120E74; Fri, 4 Jul 2014 16:52:47 -0400 (EDT)
Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-green.research.att.com (Postfix) with ESMTP id 4CEDCE042B; Fri, 4 Jul 2014 16:47:42 -0400 (EDT)
Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Fri, 4 Jul 2014 16:48:44 -0400
From: "MORTON, ALFRED C (AL)" <acmorton@att.com>
To: Barry Constantine <Barry.Constantine@jdsu.com>, "ippm@ietf.org" <ippm@ietf.org>
Date: Fri, 04 Jul 2014 16:48:42 -0400
Thread-Topic: [ippm] RFC 2679bis and RFC 2680bis and draft-ietf-ippm-testplan-rfc2680
Thread-Index: Ac94Ldpbl13tFwfNRqu7VHkTCuyiHQfk6bHA
Message-ID: <2845723087023D4CB5114223779FA9C80189AAD4F6@njfpsrvexg8.research.att.com>
References: <DE2AAE0A8826CF4ABC3A6CCB756356EB2EFED6@AMEXMB01.ds.jdsu.net>
In-Reply-To: <DE2AAE0A8826CF4ABC3A6CCB756356EB2EFED6@AMEXMB01.ds.jdsu.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C80189AAD4F6njfpsrvexg8re_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/WIJfQEQRlubpCSf45dPQrkXFBqg
Subject: Re: [ippm] RFC 2679bis and RFC 2680bis and draft-ietf-ippm-testplan-rfc2680
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jul 2014 20:48:48 -0000

Hi Barry,

thanks again for your comments on the -bis drafts,
some replies below, ACM:

regards,
Al

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Barry Constantine
Sent: Sunday, May 25, 2014 12:18 PM
To: ippm@ietf.org
Subject: [ippm] RFC 2679bis and RFC 2680bis and draft-ietf-ippm-testplan-rfc2680


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?



RFC 6291 is dated April 1st...



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.



ACM: clearly delay of both directions contributes to RTT, as the queues grow in the forward direction they may tend to dominate, a la buffer bloat.  I clarified this briefly.



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.



ACM: One of the IESG comments on the RFC2330 update resulted in adding this text,

when mentioning compression (approx. same added here):



We note that use of transport layer encryption will counteract the deployment of

network-based analysis and may reduce the adoption of payload optimizations, however.





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...



ACM: mentioned this, both Nalini and Joachim have raised this point too.



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.



ACM: in this day and age, tracert packets and measurement packets can easily follow different paths



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?



ACM: I think this is an on-going check for congestion, packets will certainly be lost if the buffers fill.

Although you proposed a lab calibration, which is fine, http://tools.ietf.org/html/rfc6815 is worth noting.



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?



ACM:  According to the metric definitions, each packet gets an unambiguous wire-time, T.

So, the packet at time T is either lost or not.  If a TCP segment is retransmitted, it

gets a later wire-time, T, and is treated individually.



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.)



ACM: my guess is that answers for TCP appear in the BTC framework

http://tools.ietf.org/html/rfc3148



Section 4.1:



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



ACM: it's mostly to provide background for a comment about statistics, which is still valid.



****

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


Thank you,
Barry Constantine