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
- [ippm] RD and TCP retransmit analysis Nischal M Piratla
- Re: [ippm] RD and TCP retransmit analysis Al Morton
- Re: [ippm] RD and TCP retransmit analysis Nischal M. Piratla
- RE: [ippm] RD and TCP retransmit analysis Nischal M Piratla
- Re: [ippm] RD and TCP retransmit analysis Al Morton