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

[Alexander Zimmermann <[e-mail]>]

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

Am 11.11.2008 um 21:41 schrieb Ethan Blanton:

> 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

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: [phone], fax: [phone]
// email: [e-mail]
// web: http://www.umic-mesh.net
//

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