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
- [ippm] WGLC announcement for draft-ietf-ippm-test… Brian Trammell
- Re: [ippm] WGLC announcement for draft-ietf-ippm-… Joachim Fabini
- Re: [ippm] WGLC announcement for draft-ietf-ippm-… MORTON, ALFRED C (AL)