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

[Barry Constantine <[e-mail]>]

Hi Rudi,

Just to properly close these comments; we agree to the Section 1. and 2. comments and will incorporate this into the final draft.

Looking at your comments from today and will get back to you this week.

Thanks,

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: Friday, September 10, 2010 9:26 AM
To: Barry Constantine
Cc: [e-mail]
Subject: RE: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt

Hi Barry,

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

Regards, Ruediger

-----

1. Introduction - Editorial

Last section may be reworded to

   This framework proposes a test which should be performed in addisiont 
   to traditional Layer 2/3 type tests, which are conducted to verify the 
   integrity of the network before conducting TCP tests. Examples include 
   RFC 2544 [RFC2544], iperf (UDP mode), or manual packet layer test 
   techniques where packet throughput, loss, and delay measurements 
   are conducted.
----

2. Goals of this Methodology

...are not intended to be measured or analyzed by such a methodology.

Please add
   - a method to operate permanently with high measurement loads. TCP 
     performance and optimisation data of operational networks may be 
     captured and evaluated by using data of the "TCP Extended 
     Statistics MIB" [RFC4898]. 

<-- Please add a reference to RFC 4898 or explain why it can't be used -->

----

2.2 Metrics for TCP Throughput

Henk had a comment here which may have been caused by the lack of a 
definition of "transmitted bytes". Please add a definition of the terms 
"Transmitted bytes" and "retransmitted Bytes". If the former is the sum of 
"Succesfully transmitted bytes" and "retransmitted bytes", that would solve 
Henk's problem, as then Transmitted Bytes > Retransmitted Bytes. 

Effectively your formula then is: received bytes/transmitted bytes.

You introduce some type P like singletons in the following:

- type-P-TCP Transmitted Bytes
- type-P-TCP Retransmitted Bytes
- type-P-TCP Efficiency (you've defined a formula)

These depend on a number of parameters which may vary:
RTT, Packet Loss, MSS, Path Capacity, MTU size and the time when 
you've measured.

You then introduce another two type P like singletons, 

- type-P-TCP Actual Transfer Time
- type-P-TCP Transfer Index

In adition to the above parameters, both depend on a data block size 
and the transfer index in addition depends on an "ideal TCP transfer 
time".

There's no definition of the "ideal TCP transfer time" - at least I didn't 
see any before or immediately after the Transfer Index is introduced.  
This should be added.

I've tried to scetch some Type-P language here and based it on your 
input. I leave it to you to pick it up. I'm not an expert on type p 
definitions, this definitely requires more work.

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