Subject: [ippm] Document Action: 'Test Plan and Results for Advancing RFC 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm-testplan-rfc2680-05.txt)

From: Nalini Elkins <[email-masked]>
Date: Mon, 12 May 2014 08:09:14 -0700 (PDT)

Al,

Some comments on draft-morton-ippm-2679-bis-04.txt:

1. The items in section 1 of RFC2679bis (delay) appear to be implemented in the draft but I am having a bit of trouble with understanding:

"Further, enforcing a specific constant waiting time on stored singletons of one-way delay is compliant with this specification and may allow the results to serve more than one reporting audience."

I am not finding the discussion of constant waiting time with regard to singletons.  Is it in the test plan document?

2.  I also had a comment on Section 3.7.2 Errors or uncertainties related to Wire-time vs Host-time

I have had some discussions with folks about the idea of offloading the processing of the timestamps onto hardware.  That is, performing these kind of functions on a chip.  I wonder if that changes the conversation here a bit?  

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 12 May 2014 15:49:10 -0400

Hi Nalini,

You raise an important point in question 1.
The original authors of 2679 (delay, or 2680 for loss) did not include
the constant waiting time threshold as an input parameter
(and so they didn't spend much time describing it).
However, it is included explicitly  
(as parameter Tmax) in https://tools.ietf.org/html/rfc6049#section-3.1.1
and discussed in more detail in https://tools.ietf.org/html/rfc6703#section-4.1
Also, ITU-T Rec Y.1540 for IP metrics uses the parameter Tmax as
part of their loss & delay definitions, and we have a long-standing goal
to move IPPM and ITU-T definitions closer together when possible
(rather than highlight the differences and leave them alone).

In short, I think it would be a very reasonable clarification (for both "bis" drafts)
to make this constant waiting time parameter more explicit now - excellent catch!

on 2, wire time error, there would continue to be some
small time difference between external appearance of a packet
and the interface hardware time stamp, although very much less
difference than TS up in the stack. So it's a smaller error
but I think the discussion still holds.

thanks for your time and careful reading!
Al
________________________________________
From: ippm [[email-masked]] On Behalf Of Nalini Elkins [[email-masked]]
Sent: Monday, May 12, 2014 11:09 AM
To: [email-masked]
Subject: [ippm] Document Action: 'Test Plan and Results for Advancing RFC 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm-testplan-rfc2680-05.txt)

Al,

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: <[email-masked]>
Date: Fri, 23 May 2014 09:46:51 +0200

Hi Al,

I apologise for probably having missed the deadline. Some comments applying to RFCs 2679 and 2680 informative sections. I don't insist on these changes or my text proposals, but a review of the TCP related text may be useful.

Regards, Ruediger

Section Motivation

OLD + In today's Internet, the path from a source to a destination may be
   different than the path from the destination back to the source
   ("asymmetric paths"), ......Measuring each path independently highlights the
   performance difference between the two paths which may traverse
   different Internet service providers, and even radically different
   types of networks (for example, research versus commodity networks,
   or ATM versus packet-over-SONET).

NEW ......Measuring each path independently highlights the
   performance difference between the two paths which may traverse
   different Internet service providers, and even radically different
   types of networks (for example, research versus commodity networks 
   or wireline access portion versus wireless one).

The originally given example is outdated. Not sure about the quality of 
the new one but access multiplexers definitely exist.

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

NEW: + Performance of an application may depend on the performance
   in one direction. For example, a TCP based communication may experience 
   reduced throughput if congestion occurs in one direction of its communication. 
   Trouble shooting is simplified, if the congested direction of a TCP connection 
   can be directly identified.

The old text may raise the impression that delaying ACKs by congestion or 
dropping them has little impact on TCP throughput. That's not generally true, 
ACKs in a bloated buffer decrease the data flow performance. Bufferbloat 
wasn't an issue when the RFCs were written.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 23 May 2014 09:35:43 -0400

Hi Rüdiger, 

You haven't missed a deadline, and thanks for reviewing and commenting
on the 2679bis and 2680bis memos! Others may wish to take a look, too:

http://tools.ietf.org/html/draft-morton-ippm-2679-bis-04.txt
http://tools.ietf.org/html/draft-morton-ippm-2680-bis-02.txt

If more folks take a look and support these drafts for adoption/advancement,
we can move these two fundamental metrics up the Standards Track 
(something of a milestone for IPPM - we haven't accomplished this yet
for any of our metric RFCs).

These are both reasonable updates to the information provided, IMO.

regards,
Al

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 23, 2014 3:47 AM
> To: MORTON, ALFRED C (AL)
> Cc: [email-masked]
> Subject: AW: [ippm] Document Action: 'Test Plan and Results for Advancing
> RFC 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm-
> testplan-rfc2680-05.txt)
> 
> Hi Al,
> 
> I apologise for probably having missed the deadline. Some comments
> applying to RFCs 2679 and 2680 informative sections. I don't insist on
> these changes or my text proposals, but a review of the TCP related text
> may be useful.
> 
> Regards, Ruediger
> 
> 
> 
> Section Motivation
>