Re: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt - part 3

[Barry Constantine <[e-mail]>]

Hi Rudi,

We really appreciate you taking the time to provide really good comments.

All have been very insightful, especially this last round.

I'll contact you off-list and I would like to schedule time to review all comments.  I think we can more efficiently work through these collaboratively (real-time).

Thanks again,

Barry

 

Principal Member of Technical Staff

 

JDSU Communication Test (formerly Acterna)

Emerging Markets and Technology Research         

One Milestone Center Court                              

Germantown, MD 20876                                         

(W) 240-404-2227                                                

(C) 301-325-7069


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, September 16, 2010 10:27 AM
To: Barry Constantine
Cc: [e-mail]
Subject: RE: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt - part 3

Hi Barry,

Part 3 of the comments. 

Regards, Ruediger


-----

Sections 3.1 and 3.2 (MTU, Round Trip and Bandwidth Measurement)

The text does not consider the effect of ECMP (IP load sharing). 
As soon as Flow Aware Transport (FAT) is deployed, the delays will 
vary depending on the path taken through the network. If the 
document doesn't consider the application of ECMP with FAT, 
please state so explicitely.

I've missed references to RFC 2681 (RTD) and RFC 5136 (network 
capacity). On the latter, I'd be interested which of the metrics 
proposed there would determine "bandwidth" in the sense of your 
draft.

With regard to RTT determination, a reference to RFC 4898 should 
be included.

Section 3.2

..."Since this 
   methodology requires that RTT be measured during the entire 
   throughput test, the extent by which the RTT varied during the 
   throughput test can be quantified."

I don't recall any prior statement that the RTT must/MUST be 
measured during the entire test and the metrics suggested don't 
require RTT measurement. If you want to define an additional 
metric here, please provide more text and a metric definition. 
The same applies to section 3.2.2:

  ..."Ideally, the bandwidth test should produce a log output of the 
   bandwidth achieved across the test interval AND the round trip delay.  

   
   And during the actual TCP level performance measurements (Sections
   3.3 - 3.5), the test tool must be able to track round trip time
   of the TCP connection(s) during the test.  Measuring round trip time
   variation (aka "jitter") provides insight into effects of congestive
   delay on the sustained throughput achieved for the TCP layer test."

In addition to an RTT based metric, here you seem to suggest another 
metric linking RTT and bandwidth measurement.

-----

Section 3.3.1

The diagrams at the end of the section are certainly interesting 
illustrations, but they may be moved to an appendix. 

-----

Section 3.3.2 after

..."Dedicated test equipment will generally be required, especially for 
   line rates of GigE and 10 GigE."

Should you create a measurement load of more than 10% of any provider 
backbone link bandwidth on a packet based network, you SHOULD agree 
your testing activity with the network operating center prior to 
performing these tests.

The same sentence may be added to section 3.4 Traffic management tests, 
after the same sentence as above.

-----
Section 3.3.2

   "The TCP throughput test should be run over a a long enough duration 
   to properly exercise network buffers and also characterize
   performance during different time periods of the day.  The results 
   must be logged at the desired interval and the test must record RTT 
   and TCP retransmissions at each interval. 

   This correlation of retransmissions and RTT over the course of the 
   test will clearly identify which portions of the transfer reached
   TCP Equilbrium state and to what effect increased RTT (congestive
   effects) may have been the cause of reduced equilibrium performance.

   Additionally, the TCP Efficiency and TCP Transfer time metrics should
   be logged in order to further characterize the window size tests."

Please clarify and define in your text, which metrics are of true 
relevance and which are nice to have. You apply strong requirement 
language here to capture a metric which isn't defined in your document 
(retransmission to RTT correlation). The metrics you've defined so far 
"should be performed additionally". This raises the impression that the
truly required metrics of this document aren't explicitely defined, 
I think.

-----

Finally, I wonder whether any default settings may be mentioned or 
approximately validated (you can't always reach them):

- max MTU (should be part of a contract - respect layering aspects)
- access bandwidth (may well be the bottleneck).
- a maximum delay (which may be part of an SLA)
- a default TCP window setting (you mention 64KB)


----------That's it--------