Re: [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)

["MORTON, ALFRED C (AL)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> Sent: Friday, May 23, 2014 3:47 AM
> To: MORTON, ALFRED C (AL)
> Cc: [e-mail]
> 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
> 
> 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.