[e2e] Some questions about TCP.

Noel Chiappa jnc at mercury.lcs.mit.edu
Sun Nov 22 14:47:42 PST 2009

    > 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?

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

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

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. (I can't be bothered to go
dig out the hardcopy listings of the TCP I did, to see if I did, but I think
I did.) 

    > However, RFC 793 states that in "established" state, a packet's ACK
    > flag is always set.

Yes, that matches my memory.


More information about the end2end-interest mailing list