Let's say there is a network that sometimes delivers data with extreme delays. And there is a protocol that uses a "sliding window" algorithm for tracking packets acknowledgement. And imagine such a situation:
- The transmitter sends a packet and then re-transmits it because it didn't get an acknowledgement.
- Some of these re-transmitted packets get delayed.
- Then it finally gets an acknowledgement and the transmission proceeds.
- The receiver window finally makes a full round-trip and is being positioned at the position when the excessive re-transmitting was done in
1.. - Some of re-transmitted packets delayed in
2.finally arrive. - Receiver mistakenly thinks that they belong to the current window "cycle" and process them while it shouldn't be done because they are duplicate.
So essentially a question is – how to detect duplicate packets from previous window "cycles"? What are commonly used methods for dealing with such situations?
Best Answer
I'm also of the view this is phenomenally unlikely and poses no real problem in any network I know about. So the answer to "commonly-used methods" against it is that there aren't any.
However, you could build a malicious router which would do this: capture (in flight somewhere) a few packets, wait for the sequence numbers to go round, then replay them and we'd trigger this situation. What would happen would depend on the upstairs protocols, which in real life would have to be something like scp or rsync (copy big file) or some streaming service (cctv up for ever?). What else will keep a TCP open for 4GByte? (So perhaps the answer is: "situation is usually prevented because the stream never wraps its sequence numbers because it is too short."
For protocol issues, I note that RFC 7323 "TCP extensions for high performance" covers this exact issue with "PAWS" (protection against wrapped sequences). https://www.rfc-editor.org/rfc/rfc7323#section-5
A quick search shows there's some mention of this in haiku-os and Linux kernel, but I've no knowledge of how much is actually implemented.
Kind regards,
Jonathan.