Re: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680

"Joachim Fabini" <Joachim.Fabini@tuwien.ac.at> Fri, 18 October 2013 18:43 UTC

Return-Path: <Joachim.Fabini@tuwien.ac.at>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0538511E82FF for <ippm@ietfa.amsl.com>; Fri, 18 Oct 2013 11:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.981
X-Spam-Level:
X-Spam-Status: No, score=-3.981 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdSJb6LSZv-r for <ippm@ietfa.amsl.com>; Fri, 18 Oct 2013 11:43:52 -0700 (PDT)
Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id E301911E81B8 for <ippm@ietf.org>; Fri, 18 Oct 2013 11:43:51 -0700 (PDT)
Received: from centri (213-240-99-26.adsl.highway.telekom.at [213.240.99.26]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id r9IIhkbV004125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 18 Oct 2013 20:43:46 +0200
From: Joachim Fabini <Joachim.Fabini@tuwien.ac.at>
To: ippm@ietf.org
References: <202A7446-2F22-4F9B-9378-C6554249C6BB@tik.ee.ethz.ch>
In-Reply-To: <202A7446-2F22-4F9B-9378-C6554249C6BB@tik.ee.ethz.ch>
Date: Fri, 18 Oct 2013 20:43:40 +0200
Message-ID: <020801cecc31$f6ed3e50$e4c7baf0$@Fabini>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7ACuEntCBQY3IiQHmU83eQWMDaaQMJSMMg
Content-Language: en-ie
Subject: Re: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Oct 2013 18:43:58 -0000

Dear group,

I support the test plan draft and have added below some minor
remarks/comments/typos which might help in improving clarity. 

regards
Joachim

General remark (applies mainly to RFC6808, which I read as introductory
document and a potential future "advancement of round-trip delay document".
For the 2680 testplan it should have a minor effect, affecting only the time
value after which a packet is considered as lost). We have discussed this in
previous emails with Al: NetEm _might_ be an important additional source of
error. NetEm's resolution typically equals the system kernel tick (Hz
value). In some Linux distributions (Ubuntu, Debian) the kernel tick is by
default configured at 250Hz, such that an uncertainty value of 4ms is
introduced (kernel compile with appropriate settings can increase the tick
to 1000 Hz). Fedora seems to have by default 1000 Hz settings, which results
in 1ms uncertainty. And recently a tickless operation has been introduced
but I don't know if/how this affects NetEm. Abstracting from these technical
settings, I propose to make these decisions and potential uncertainty
sources explicit by mentioning them in the documents.

- Page 7, Figure 1, upper: A detailed description of the figure, its
notations, components and instances could be added. In particular I could
not find any description about mapping the two Imp1 and two Imp2 instances
to actual components/implementations. Are the Imp1's Netprobes and Imp2's
Perfas, ore vice-versa? Is one of the two identically-labelled
boxes/instances send-only and one receive-only? Or do the instances change
for distinct tests, depending on the specific test? This might be detailed
accurately in the text (what Imp1 and Imp2 rectangles are and how they
relate to the figure and what their role for these tests is).

- Page 7, Figure 1, upper vs. lower: The mapping between the upper figure
and lower one is not obvious to me. Is Imp1 in the lower figure one instance
of an Imp1 box in the upper figure, or is it an aggregation of the two Imp1
instances in the upper figure? Could be explained in text.

- Page 7, Figure 1, lower: I miss NetEm in the lower figure. 
According to the upper figure 1, the U-turn for V100 and V200 seems to be
implemented in the right Ethernet switch. So the netem instance should be
part of the flow representation, too (inserted between Internet and Remote
Switch - imho important issue, as it is the one which impairs/drops the
traffic and might introduce additional uncertainties)

- Page 20: Section 6.4.1: From a strictly technical point of view (affecting
the timeout interval after which a packet is considered to be lost), it
might make a difference whether timestamps are acquired before or after the
system call. So the point in time when timestamp acquisition is scheduled
should be defined unambiguously.


-------------------- Layout, typos, etc. ---------------- 
- Page 4, second paragraph ("A renewed work...") - it is not clear to me
whether this paragraph is related to the third paragraph and references
RFC6567 (merge the two in this case?). Alternatively a reference/citation
could be added to the second paragraph.
- Page 4, next-to-last paragraph: is it acceptable to reference an ID
(I-D.morton-ippm-advance-metrics) from here?
- Page 5, Section 2, second paragraph: typo "the an equivalent"
- Page 8: Add reference to "mii-tool"? (btw, as a side-node: mii-tool seems
to be deprecated on some Linux distributions, being replaced by ethtool)
- Page 8: Typo (DCSP instead of DSCP?)
- Page 10: I'd propose to mark and delimit start and end of the traceroute
output visually - perhaps add a caption (Netprobe traceroute)?
- Page 11: third paragraph, typo ("was be")
- Page 14: Perhaps it would improve readability to delimit the R output (on
this page and all subsequent occurrences) visually and add a caption?
- Page 23: section 6.4.3: typo "distributions when according"

> -----Original Message-----
> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of
> Brian Trammell
> Sent: 03 October 2013 09:32
> To: ippm@ietf.org
> Subject: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680
> 
> Greetings, all,
> 
> As discussed in Berlin, "Test Plan and Results for Advancing RFC 2680
> on the Standards Track", draft-ietf-ippm-testplan-rfc2680, is ready for
> Working Group Last Call (WGLC); this message begins that last call.
> Please direct any final comments on this draft to the ippm@ietf.org
> mailing list by Friday 18 October 2013.
> 
> Many thanks, best regards,
> 
> Brian