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

<Ruediger.Geib@telekom.de> Fri, 10 September 2010 13:26 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A043A6A4B for <ippm@core3.amsl.com>; Fri, 10 Sep 2010 06:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.583
X-Spam-Level:
X-Spam-Status: No, score=0.583 tagged_above=-999 required=5 tests=[AWL=-3.027, BAYES_20=-0.74, GB_SUMOF=5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcwvBmu6YUj3 for <ippm@core3.amsl.com>; Fri, 10 Sep 2010 06:26:27 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 3D2403A6A4A for <ippm@ietf.org>; Fri, 10 Sep 2010 06:26:27 -0700 (PDT)
Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 10 Sep 2010 15:26:28 +0200
Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Sep 2010 15:26:28 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Sep 2010 15:26:26 +0200
Message-ID: <151C164FE2E066418D8D44D0801543A504B0DFD9@S4DE8PSAAQA.mitte.t-com.de>
In-Reply-To: <94DEE80C63F7D34F9DC9FE69E39436BE38B9FF2C81@MILEXCH1.ds.jdsu.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt
Thread-Index: ActI5hDf36OqIEzkTBesOmMMqCSfmwABnUUgAJsBURAAlg2kIACAkdzQAEvRcvA=
References: <4C7CBBFD.1030402@ripe.net> <151C164FE2E066418D8D44D0801543A5049C88F8@S4DE8PSAAQA.mitte.t-com.de> <94DEE80C63F7D34F9DC9FE69E39436BE38B9F4E14F@MILEXCH1.ds.jdsu.net> <151C164FE2E066418D8D44D0801543A504A56E4D@S4DE8PSAAQA.mitte.t-com.de> <94DEE80C63F7D34F9DC9FE69E39436BE38B9FF2C81@MILEXCH1.ds.jdsu.net>
From: Ruediger.Geib@telekom.de
To: Barry.Constantine@jdsu.com
X-OriginalArrivalTime: 10 Sep 2010 13:26:28.0075 (UTC) FILETIME=[C6114BB0:01CB50EB]
Cc: ippm@ietf.org
Subject: Re: [ippm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ippm>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2010 13:26:28 -0000

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--------