RE: [ippm] RD and TCP retransmit analysis

Nischal M Piratla <nischal@engr.colostate.edu> Sat, 02 April 2005 00:19 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06252 for <ippm-archive@lists.ietf.org>; Fri, 1 Apr 2005 19:19:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWJ7-0005Wp-In; Fri, 01 Apr 2005 19:16:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWJ5-0005Wk-UU for ippm@megatron.ietf.org; Fri, 01 Apr 2005 19:16:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06066 for <ippm@ietf.org>; Fri, 1 Apr 2005 19:16:04 -0500 (EST)
Received: from eagle.acns.colostate.edu ([129.82.100.90] helo=eagle.colostate.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWQW-0005fL-7W for ippm@ietf.org; Fri, 01 Apr 2005 19:23:48 -0500
Received: from engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by eagle.colostate.edu (AIX5.1/8.11.6p2/8.11.0) with ESMTP id j320G6S1565378 for <ippm@ietf.org>; Fri, 1 Apr 2005 17:16:06 -0700
Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by engr.colostate.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j320G5f08197 for <ippm@ietf.org>; Fri, 1 Apr 2005 17:16:05 -0700 (MST)
X-WebMail-UserID: nischal@mail.engr.colostate.edu
Date: Fri, 01 Apr 2005 17:16:05 -0700
From: Nischal M Piratla <nischal@engr.colostate.edu>
To: ippm@ietf.org
X-EXP32-SerialNo: 00002247, 00002264
Subject: RE: [ippm] RD and TCP retransmit analysis
Message-ID: <42A92359@webmail.colostate.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org
Content-Transfer-Encoding: 7bit

I wanted to add this line in my response:
TCP retransmit analysis for any metric may not be useful as Mark Allman and 
others are working on this very interesting draft:
draft-ietf-tcpm-tcp-dcr-03.txt
- Nischal

>===== Original Message From "Nischal M. Piratla" <nischal@engr.colostate.edu> 
=====
>Al Morton wrote:
>
>> Consider this example:
>> Arrivals:            1   4   5   6   7   3   2
>> ACKs:                   2   2  2   2  2   2
>> Receive_index:       1   2   3   4   5   6   7
>> Displacement:        0  -2  -2  -2  -2   3   5
>>
>> Is this an example of one of the circumstances you've excluded?
>> (with the following sentence)
>>
>>> In addition, if a packet is reordered then the following packets
>>> in the sequence are not reordered with same or higher displacement.
>>
>No, there is always a duplicate ACK per packet after an out-of-order
>arrival. So, 2 will be retransmitted after 3rd duplicate ACK arrives,
>i.e., retransmitted packet arrives after 6. Thus, there is no packet
>with displacement greater than 3 before packet with sequence number 2.
>
>>
>> In any case, how many arrivals must occur before Displacement
>> can be evaluated again?
>> IOW, the condition quoted above may also exclude this case:
>> Arrivals:  1 3 4 5 6 2 7 9 10 11 12 8
>> Displacement:        4              4
>> but this seems to be a case where there may be two re-transmissions.
>>
>Again, per packet ACK after an out-of-order answers this concern.
>
>> We have not placed strong requirements like this on the measured
>> stream in the past, and this one appears to need some refinement.
>
>Unless, I am mistaken there was no such explicit analysis for any of the
>metrics. So, I am not sure what it means when you say we have not placed
>strong requirements in the past. This analysis was made taking
>statements from RFC 2581 and RFC 1122 into consideration. However, we
>will  welcome your comments/suggestions on any refinements, if you feel
>are necessary.
>- Nischal
>
>
>_______________________________________________
>ippm mailing list
>ippm@ietf.org
>https://www1.ietf.org/mailman/listinfo/ippm

****************************************************
Research Assistant
Computer Networking Research Laboratory (CNRL)
C203,Dept. of Electrical & Computer Eng.
Colorado State University,
Fort Collins, CO 80523
Voice: 970-491-7067/7794
Fax:   970-491-2249
http://www.cnrl.colostate.edu
http://lamar.colostate.edu/~nischal
****************************************************


_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm