Revision history [back]

Interesting question. Here is what I think. At first: if S2 and S3 are packets in sequence after S1, the situation you've described cannot happen at all.

Why? You write:

"WHILE the recipient was sending the Dup Ack packets, the sender has sent 2 packets..."

Whereas generating Dup ACKs is not time-based event, it's event-driven. If the recipient doesn't get S2 and S3 - it will not send any ACKs at all after S0 (packet that had come before lost S1). So in your case even after receiving S2 and S3 recipient will generate only 2 Dup ACKs that will not cause (in most TCP stacks) Fast Retransmission.

But let's assume packet S4 came, and 3rd Dup Ack was sent to sender. In that case sender's and receiver's behaviour will be determined by TCP stacks they're using.

Most modern stacks are capable to do selective repeat. It that case you're right, the next Ack from recipient would be S4+len (remember, we added one more packet!).

But if tou deal with really old stack (or maybe some IOT stack) than can do only go-back-n, the recipient will discard any out-of-order packets and request S2, S3,S4 one more time until it receives all the packets in correct order.

Interesting question. Here is what I think. At first: if S2 and S3 are packets in sequence after S1, the situation you've described cannot unlikely to happen at all.

Why? You write:

"WHILE the recipient was sending the Dup Ack packets, the sender has sent 2 packets..."

Whereas generating Dup ACKs is not time-based event, it's event-driven. If the recipient doesn't get S2 and S3 - it will not send any ACKs at all after S0 (packet that had come before lost S1). So in your case even after receiving S2 and S3 recipient will generate only 2 Dup ACKs that will not cause (in most TCP stacks) Fast Retransmission.

But let's assume packet S4 came, and 3rd Dup Ack was sent to sender. In that case sender's and receiver's behaviour will be determined by TCP stacks they're using.

Most modern stacks are capable to do selective repeat. It that case you're right, the next Ack from recipient would be S4+len (remember, we added one more packet!).

But if tou deal with really old stack (or maybe some IOT stack) than can do only go-back-n, the recipient will discard any out-of-order packets and request S2, S3,S4 one more time until it receives all the packets in correct order.

Interesting question. Here is what I think. At first: if S2 and S3 are packets in sequence after S1, the situation you've described is unlikely to happen at all.

Why? You write:

"WHILE the recipient was sending the Dup Ack packets, the sender has sent 2 packets..."

Whereas generating Dup ACKs is not time-based event, it's event-driven. If the recipient doesn't get S2 and S3 - it will not send any ACKs at all after S0 (packet that had come before lost S1). So in your case even after receiving S2 and S3 recipient will generate only 2 Dup ACKs that will not cause (in most TCP stacks) Fast Retransmission.

But let's assume packet S4 came, and 3rd Dup Ack was sent to sender. In that case sender's and receiver's behaviour will be determined by TCP stacks they're using.

Most modern stacks are capable to do selective repeat. It that case you're right, the next Ack from recipient would be S4+len (remember, we added one more packet!).

But if tou deal with really old stack (or maybe some IOT stack) than can do only go-back-n, the recipient will discard any out-of-order packets and request S2, S3,S4 one more time until it receives all the packets in correct order.

Interesting question. Here is what I think. At first: if S2 and S3 are packets in sequence after S1, the situation you've described is unlikely to happen at all.

Why? You write:

"WHILE the recipient was sending the Dup Ack packets, the sender has sent 2 packets..."

Whereas generating Dup ACKs is not time-based event, it's event-driven. If the recipient doesn't get S2 and S3 - it will not send any ACKs at all after S0 (packet that had come before lost S1). So in your case even after receiving S2 and S3 recipient will generate only 2 Dup ACKs that will not cause (in most TCP stacks) Fast Retransmission.

But let's assume packet S4 came, and 3rd Dup Ack was sent to sender. In that case sender's and receiver's behaviour will be determined by TCP stacks they're using.

Most modern stacks are capable to do selective repeat. It that case you're right, the next Ack from recipient would be S4+len (remember, we added one more packet!).

But if tou deal with really old stack (or maybe some IOT stack) than can do only go-back-n, the recipient will discard any out-of-order packets packet and request S2, S3,S4 S3, S4 one more time until it receives all the packets in correct order.