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

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

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

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

Attachment: signature.asc