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)

[<[e-mail]>]

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.