Re: [tcpm] RFC 2883 (D-SACK), Section 5.1 Replication by the network

Ethan Blanton <> Tue, 11 November 2008 20:41 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 84DC13A6925; Tue, 11 Nov 2008 12:41:20 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A23693A6925 for <>; Tue, 11 Nov 2008 12:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.005
X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FS_REPLICA=0.994, J_CHICKENPOX_33=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PxB9Ai9lyqZU for <>; Tue, 11 Nov 2008 12:41:19 -0800 (PST)
Received: from ( [IPv6:2001:418:1::62]) by (Postfix) with ESMTP id C6B5A3A6822 for <>; Tue, 11 Nov 2008 12:41:18 -0800 (PST)
Received: from [] ( by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <>) id 1L0030-000AIA-Ki; Tue, 11 Nov 2008 20:41:17 +0000
Received: from colt.internal (colt []) by (Postfix) with ESMTP id 7CACB2BE23; Tue, 11 Nov 2008 15:41:12 -0500 (EST)
Received: by colt.internal (Postfix, from userid 3000) id AEF1E27F1E; Tue, 11 Nov 2008 15:41:11 -0500 (EST)
Date: Tue, 11 Nov 2008 15:41:11 -0500
From: Ethan Blanton <>
To: Alexander Zimmermann <>
Message-ID: <>
Mail-Followup-To: Alexander Zimmermann <>,
References: <> <> <>
MIME-Version: 1.0
In-Reply-To: <>
X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Subject: Re: [tcpm] RFC 2883 (D-SACK), Section 5.1 Replication by the network
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============2101553309=="

Alexander Zimmermann spake unto us the following wisdom:
> Am 08.11.2008 um 20:59 schrieb Ethan Blanton:
>> Alexander Zimmermann spake unto us the following wisdom:
>>> According 2581(bis) a TCP receiver should send immediately an DUPACK
>>> when an out-of-order segment arrives. Furthermore, 2581bis says that 
>>> a DUPACK carries no data.
>>> So, according to the DUPACK definition of 2581bis it seems to me that
>>> we have no problem to detect a packet replication in case D-SACK is
>>> not present. Right?
>> The problem here is that you have no idea whether the dupack was
>> generated by a packet already received (entirely below RCV.NXT), or a
>> packet following a lost or as yet un-received packet (entirely beyond
>> RCV.NXT).  Both of these conditions generate a duplicate
>> acknowledgment.
> you are completely right. However, in the example of section 5.1 it is  
> assumed that no segment is lost.
> IMHO the example is not correct (anymore) since it is assumed that a  
> DUPACK can be piggyback on a data packet.
> According to 2581bis a DUPACK carries no data.

You lost me, somewhere.

In the example you quote there is indeed no loss, but the example does
not need to show loss to model the utility of DSACK.  The point is,
that without the DSACK block, the sending TCP would have no way to
know that in fact there *wasn't* loss, and would have to assume that
the dupack coming back indicated that a segment above RCV.NXT had
arrived out of order.

Perhaps you should show an example timeline of packet events which you
believe unambiguously indicates that a segment was received in


The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
tcpm mailing list