[e2e] Some questions about TCP.

[Noel Chiappa]

    > From: Detlef Bosau <detlef.bosau at web.de>

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

If they contain no data, by definition they _are_ duplicate acknowledgements.
That is not necessarily a problem, though.


    > RFC 2581 Section 4.2
    >
    >   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].

That is poorly phrased. It should say 'more than one ACK-only packet', or
something like that.

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

Yes, that is OK. Just as long as one does not send multiple ACK-only packets
in response to a single data-containing packet.


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

I'm not an expert in this area of TCP, but I think you have to look at the
larger situation - i.e. look to see what exactly you have outstanding, etc.
E.g. if you send segments A, A+100, A+200, and A+300, and you get back
ACK-only packets for A, A, A then you can be fairly sure that A+100 has been
lost, and you need to re-send it. That is because you know that the A packet
got there (it was ack'd), as well as two packets _after_ the A (since the TCP
on the other end _could not_ have sent those acks _unless it saw packets_ - at
least if it's following the spec :-), but the A+100 was not seen (or it would
have been acked).

But depending on exactly what it going on, there may be no absolute
certainty. E.g. if the other side _is_ sending data in those packets (or
changing the window), then perhaps the A+100 packet, and the following
packets, just hadn't gotten there yet.

Adding timers allows you to make even better estimations of what it going on.
But, like I said, this is not my area of expertise, so perhaps someone else
can help.

	Noel