Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Undertanding SACK and Fast Retransmission

Hello, I was trying to understand how Fast Retransmission works. I downloaded an ISO image from a remote site and was analyzing the trace: sequence numbers, Dup ACKs, SACK and all that stuff. Lots of fun!

I saw how SACK's right edge grows, how another SACK buffer is added in the presence of a new 'TCP segment not captured' to the point where there can only be three buffers, then, when another 'TCP segment not captured' comes, the older seems to be flushed out.

Now, I saw the server eventually send the first Fast Retransmission, with the sequence number that the client had been desperately asking for over 200 ms (that's consistent with RTT). So far so good. But I've noticed something that I cannot explain.

The client was asking for the segment 19903603-19905043 (1440 bytes); the server finally sent that segment with the first Fast Retransmission, but then the client acknowledged 19915123. That's exactly seven segments more than the ones I expected. The SACK buffer, at that point, contained 21538003-21582643 21527923-21535123 21525043-21526483, so values that are out of range the ones that were acknowledged.

Now my question is: where did the client took the seven segments that it acknowledged?

Roberto

Undertanding SACK and Fast Retransmission

Hello, I was trying to understand how Fast Retransmission works. I downloaded an ISO image from a remote site and was analyzing the trace: sequence numbers, Dup ACKs, SACK and all that stuff. Lots of fun!

I saw how SACK's right edge grows, how another SACK buffer is added in the presence of a new 'TCP segment not captured' to the point where there can only be three buffers, then, when another 'TCP segment not captured' comes, the older seems to be flushed out.

Now, I saw the server eventually send the first Fast Retransmission, with the sequence number that the client had been desperately asking for over 200 ms (that's consistent with RTT). So far so good. But I've noticed something that I cannot explain.

The client was asking for the segment 19903603-19905043 (1440 bytes); the server finally sent that segment with the first Fast Retransmission, but then the client acknowledged 19915123. That's exactly seven segments more than the ones I expected. The SACK buffer, at that point, contained 21538003-21582643 21527923-21535123 21525043-21526483, so values that are out of range the ones that were acknowledged.

Now my question is: where did the client took take the seven segments that it acknowledged?

Roberto