[e2e] Some questions about TCP.

[Detlef Bosau]

Noel Chiappa wrote:
>     > From: Detlef Bosau <detlef.bosau at web.de>
>
>     > The problem occurs when you clock out several segments from a TCP peer.
>     > In that case, several segments / TCP packets will contain the same ack
>     > number.
>
> Yes... I see no problem here?
>   

Surely the problem is between keyboard and chair hiere....

However: How can I prevent to mistake several segments with the same ack 
number as duplicate acknowledgements?

>     > Now, the RFC states explicitly that a segment _MUST_ _NOT_ be acknowled
>     > more than once. So, how do we avoid incoming packets to be mistaken for
>     > dup acks?
>
> I'm not sure what you're referring to here? Where did you see that 'segment
> must not be acked more than once' thing? I looked in RFC-793 and found only
> three instances of "must not", none of them about ACKs.
>
>   

RFC 2581 Section 4.2
<quote>

   A TCP receiver MUST NOT generate more than one ACK for every incoming
   segment, other than to update the offered window as the receiving
   application consumes new data [page 42, Pos81][Cla82].
</quote>

So, when a node sends several segments without receiving new ones, it will repeat the same ack number several times.




> Maybe it means 'you shouldn't send more than one ACK-only packet in response
> to a single data packet', or something like that?
>
>   

It's actually MUST NOT (capitals in the RFC) in RFC 2581 ;-)


> If a TCP connection is unidirectional, then the outgoing data packets must,
> if they carry an ACK at all, have the same ACK value. It's true that since
> there is an ACK bit, one could emit packets with that bit off, but I think
> most TCPs leave it on pretty much all the time.

RFC 793 explicitly says so.

However, my problem is: When it is possible for a sender, to have the 
same packet acknowledged by several packets from the peer, not to 
mistake these for e.g. da Triple Duplicate Acknowledgement, which will 
cause the sender to go into fast retransmission and fast recovery?

Perhaps, I don't see the clue here for some reason...

Detlef

-- 
Detlef Bosau            Galileistraße 30        70565 Stuttgart
phone: +49 711 5208031  mobile: +49 172 6819937 skype: detlef.bosau     
ICQ: 566129673          detlef.bosau at web.de     http://www.detlef-bosau.de