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

From: Alexander Zimmermann <[email-masked]>
Date: Thu, 06 Nov 2008 09:25:55 +0100

Hi folks,

RFC 2883, Section 5.1 states that without D-SACK a TCP sender would
not know that a packet had been replicated in the network if the last  
ACK
was piggybacked on a data packet.

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?

Alex

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: [email-masked]
// web: http://www.umic-mesh.net
//

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Ethan Blanton <[email-masked]>
Date: Sat, 8 Nov 2008 14:59:19 -0500

Alexander Zimmermann spake unto us the following wisdom:
> ACK was piggybacked on a data packet.
>

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.

Ethan

-- 
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
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Alexander Zimmermann <[email-masked]>
Date: Tue, 11 Nov 2008 18:20:00 +0100

> RCV.NXT).  Both of these conditions generate a duplicate

Hi Ethan,

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.

Alex

//

---

From: Ethan Blanton <[email-masked]>
Date: Tue, 11 Nov 2008 15:41:11 -0500

Alexander Zimmermann spake unto us the following wisdom:
>>> 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?
>>

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

Ethan

---

From: Alexander Zimmermann <[email-masked]>
Date: Wed, 12 Nov 2008 09:55:08 +0100

Hi Ethan,

sorry that I confused you :-)

For the moment, please forget the example I quoted.

The problem that I have is maybe only a phrasing problem in RFC 2883.

Read this (RFC 2883, page 13, last paragraph):

"If D-SACK was not used and one of the ***duplicate ACKs was piggybacked
on a data packet***, the sender would not know how many duplicate  
packets
had been received."

and now read this (Draft 2581bis, page 3):

"DUPLICATE ACKNOWLEDGMENT:
An acknowledgment is considered a "duplicate" in the following  
algorithms when
(a) the receiver of the ACK has outstanding data,
(b) ***the incoming acknowledgment carries no data,***
..."

Do you see my problem?

Alex

//

---

From: Ethan Blanton <[email-masked]>
Date: Wed, 12 Nov 2008 13:13:56 -0500

> For the moment, please forget the example I quoted.
n>
> "If D-SACK was not used and one of the ***duplicate ACKs was
> piggybacked on a data packet***, the sender would not know how many
> duplicate packets had been received."

OK, so this is unlikely to happen -- but note that the following
sentence covers exactly the situation where it does not.

> (b) ***the incoming acknowledgment carries no data,***

Yes and no -- I see that 2883 describes, in part of one example, a
situation which is unlikely, and which requires that a duplicate
acknowledgment is defined in a broader sense than 2581bis.  (However,
note that 2581bis says that "Out-of-order data segments SHOULD be
acknowledged immediately, in order to accelerate loss recovery."  It
seems to me that a TCP stack which is choosing not to implement
SACK/DSACK might reasonably interpret this SHOULD in such a way that
suppresses immediate dupacks specifically for
already-received-and-acknowledged data, allowing the normal delayed
ACK timer to handle that case.  I'm not going to make an argument
either way, but I do point out that the requirement you are citing is
only a SHOULD.

I say "yes and no" because I don't see why this is an issue, or why we
should care.  So there's an example in 2883, part of which describes
an unlikely situation; the conclusion drawn from the example is still
valid.  Where is the problem?  Again, I suggest that you provide a
sequence of events which you believe indicates that DSACKs (or some
alternate explicit mechanism, such as Reiner Ludwig's clever Eifel
bits) are not required to disambiguate duplicate segment reception
from general out-of-order packet reception.

Ethan