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

Barry Constantine <Barry.Constantine@jdsu.com> Sun, 25 May 2014 16:18 UTC

Return-Path: <Barry.Constantine@jdsu.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 0B6771A031D for <ippm@ietfa.amsl.com>; Sun, 25 May 2014 09:18:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.135
X-Spam-Level: *
X-Spam-Status: No, score=1.135 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 krpFWMSecvpI for <ippm@ietfa.amsl.com>; Sun, 25 May 2014 09:18:04 -0700 (PDT)
Received: from mx0b-00158d01.pphosted.com (mx0b-00158d01.pphosted.com [67.231.152.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453DE1A0324 for <ippm@ietf.org>; Sun, 25 May 2014 09:18:03 -0700 (PDT)
Received: from pps.filterd (m0043258.ppops.net [127.0.0.1]) by mx0b-00158d01.pphosted.com (8.14.5/8.14.5) with SMTP id s4PGEXr8001919 for <ippm@ietf.org>; Sun, 25 May 2014 09:18:01 -0700
Received: from mx1.jdsu.com ([157.234.211.50]) by mx0b-00158d01.pphosted.com with ESMTP id 1m2beppv4c-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <ippm@ietf.org>; Sun, 25 May 2014 09:18:00 -0700
Received: from AMEXHTCA01.ds.jdsu.net (10.239.69.11) by mx1.jdsu.com (10.239.15.50) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 25 May 2014 09:17:58 -0700
Received: from AMEXMB01.ds.jdsu.net ([fe80::9402:2c4c:29f3:a264]) by AMEXHTCA01.ds.jdsu.net ([fe80::def:afde:7a37:2c3b%15]) with mapi id 14.03.0181.006; Sun, 25 May 2014 09:17:59 -0700
From: Barry Constantine <Barry.Constantine@jdsu.com>
To: "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: RFC 2679bis and RFC 2680bis and draft-ietf-ippm-testplan-rfc2680
Thread-Index: Ac94Ldpbl13tFwfNRqu7VHkTCuyiHQ==
Date: Sun, 25 May 2014 16:17:59 +0000
Message-ID: <DE2AAE0A8826CF4ABC3A6CCB756356EB2EFED6@AMEXMB01.ds.jdsu.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.234.234.5]
Content-Type: multipart/alternative; boundary="_000_DE2AAE0A8826CF4ABC3A6CCB756356EB2EFED6AMEXMB01dsjdsunet_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-25_02:2014-05-23,2014-05-25,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405250226
Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/aaw2o4-fmJn9ZkitkRublzKLKU8
Subject: [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: Sun, 25 May 2014 16:18:07 -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