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

From: Brian Trammell <[email-masked]>
Date: Thu, 3 Oct 2013 09:32:10 +0200

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 [email-masked] mailing list by Friday 18 October 2013.

Many thanks, best regards,

Brian

---

From: "Joachim Fabini" <[email-masked]>
Date: Fri, 18 Oct 2013 20:43:40 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Trammell
> Sent: 03 October 2013 09:32
> To: [email-masked]
> 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 [email-masked]
> mailing list by Friday 18 October 2013.
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 18 Oct 2013 16:23:37 -0400

Thanks very much for your review and comments, Joachim!
I will address these over the weekend, and ideally 
propose resolutions in the text before the deadline
on Monday...

Also, thanks to Bill and Ann Cerveny for comments and suggestions.

regards,
Al

> Joachim Fabini
> Sent: Friday, October 18, 2013 2:44 PM
> To: [email-masked]
> Subject: Re: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680
> 
> Dear group,
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm