From owner-freebsd-net Fri Feb 8 6:58: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f113.pav2.hotmail.com [64.4.37.113]) by hub.freebsd.org (Postfix) with ESMTP id B5A8A37B437 for ; Fri, 8 Feb 2002 06:57:50 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 8 Feb 2002 06:57:50 -0800 Received: from 204.178.20.14 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 08 Feb 2002 14:57:50 GMT X-Originating-IP: [204.178.20.14] From: "murthy kn" To: silby@silby.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: Duplicate Acks and Fast Retransmit Date: Fri, 08 Feb 2002 20:27:50 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Feb 2002 14:57:50.0635 (UTC) FILETIME=[FA7D8FB0:01C1B0B0] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, Thanks for the useful suggestions. I have one small doubt which I feel is reordering is happening. > > > 1. In my understanding, this should make the "sending" TCP get into Fast > > Retransmit mode each time it receives 2 identical acks (or 1 duplicate >ack). > > However, I am not seeing this behaviour and would like > > to get your advice on if I am missing something. > >One of the reasons this appears to be the case is because I don't see >duplicate acks (be careful to distinguish between duplicate acks and >window updates.) In fact, I don't really see much in the way of packet >reordering. > (A small portion of earlier dump is attached below) 10:16:02.513687 10.10.10.1.1024 > 10.10.10.2.5001: . 240369:241817(1448) ack 1 win 32942 (DF) 10:16:02.513700 10.10.10.2.5001 > 10.10.10.1.1024: . ack 240369 win 33304 (DF) 10:16:02.513714 10.10.10.1.1024 > 10.10.10.2.5001: . 241817:243265(1448) ack 1 win 32942 (DF) 10:16:02.513757 10.10.10.2.5001 > 10.10.10.1.1024: . ack 243265 win 31856 (DF) 10:16:02.513791 10.10.10.2.5001 > 10.10.10.1.1024: . ack 243265 win 33304 (DF) --------> From what I understand by reading Stevens (TCP/IP Illustrated Vol 1 pg 279), this is an example of Window Update (The window advertised by the receiver has changed and this is NOT an example of reordering) 10:16:02.513841 10.10.10.1.1024 > 10.10.10.2.5001: P 244713:246161(1448) ack 1 win 32942 (DF) 10:16:02.513889 10.10.10.2.5001 > 10.10.10.1.1024: . ack 243265 win 33304 (DF) ---------------> However, AFAIK, this is an example of Duplicate Ack due to Out-or-order arrival (i,e reorder) and NOT a Window update as the receiver is advertising the same window. The reciever has gone out of his usual ACK every other segment mode and generating an "immediate ACK for an out-of-order segment" in compliance with the TCP standards. Please correct me if I am wrong. If the above is true, I am understanding why sender is not generating a "Fast Retransmit" though he is receiving many such "Dup Acks" and "Rex threshold" is 1. 10:16:02.513905 10.10.10.1.1024 > 10.10.10.2.5001: . 243265:244713(1448) ack 1 win 32942 (DF) 10:16:02.513944 10.10.10.2.5001 > 10.10.10 Thanks, Murthy _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message