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

[<[e-mail]>]

Hi Barry,

Part 2 of the comments. Edirorial text changes express my taste. I don't insist on them. Comments Part 3 follows, if time allows.

Regards, Ruediger


-----

A general comment: the document does not offer any section on 
terminology or test set up architecture. This causes a fair 
share of my questions.

-----

3. TCP Throughput Testing Methodology

....
4. Traffic Management Tests.  ....
   Multiple connection testing can verify that the network is configured
   properly for traffic shaping versus policing, various queueing 
   implementations, and RED.

<Please clarify which network element configurations are supposed to be 
characterised that way, eg. CE routers, PE routers, P routers or all 
network elements along a path. If PE or P routers are to be tested, 
please add a statement whether you expect such tests to be carried 
out by the operational staff of the provider or in cooperation with 
these.>

----

Same section, later

   Whether the TCP test host is a standard computer or dedicated test
   instrument, the following areas should be considered when selecting
   a test host:

   - TCP implementation used by the test host OS, i.e. Linux OS kernel 
   using TCP Reno, TCP options supported, etc.  This will obviously be 
   more important when using custom test equipment where the TCP 
   implementation may be customized or tuned to run in higher 
   performance hardware

<If there is any requirement to use a standard conformant TCP 
implementation, the text should express this using standard language. 
Is it clear to any reader why exactly the TCP implementation 
is an issue by just reading the above text? Or do you expect a certain 
know how level to understand this issue?  MUST or SHOULD the 
implementation used by the test equipment be recorded when performing 
a test?>

----

Same section, later

   - Most importantly, the TCP test host must be capable of generating 
   and receiving stateful TCP test traffic at the full link speed of the 
   network under test. As a general rule of thumb, testing TCP 
   throughput at rates greater than 100 Mbit/sec generally requires high
   performance server hardware or dedicated hardware based test tools.

<Is the first "must" meant to be a "MUST"?>
<Please clarify whether the "network under test" is the Layer 2/3 VPN with 
the access bandwidth agreed for this network or the complete provider 
network accross which the Layer 2/3 VPN is produced.>

----

Same section, later

   - To measure RTT and TCP Efficiency per connection, this will 
   generally require dedicated hardware based test tools. In the absence
   of dedicated hardware based test tools, these measurements may need 
   to be conducted with packet capture tools (conduct TCP throughput 
   tests and analyze RTT and retransmission results with packet 
   captures).

<Please add a reference for the "TCP Extended Statistics MIB" [RFC4898] 
and adapt text, as this might be a way get around dedicated test 
equipment and packet capture tools.> 

<Please add an additional section expressing something like:>

  - The test equipment and its acces to the network under test MUST NOT 
introduce a performance bottleneck of any kind.

----------Finish for today--------