 | 1 | initial version |
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.
There is no rule in TCP directly limiting the number of SACK blocks that can be present in the TCP header, but there is a rule that limits the size of the TCP header to 60 bytes, which indirectly limits the number of SACK blocks that can be present. If no other options are present, there can be up to four SACK blocks. If other options are present, there will be less room for SACK blocks, which is why you never saw more than three SACK blocks.
The client was asking for the segment 19903603-19905043 (1440 bytes);
It's more accurate to say that the receiver (client) was asking for the segment beginning with sequence number 19903603. The client doesn't know how many bytes are in the segment until it is received.
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
Now my question is: where did the client take the seven segments that it acknowledged?
I have to add that, at the beginning of the Dup ACKs, the segment 19905043-19915123 was tracked in the client's SACK, before being flushed out by newer 'TCP segments not captured'
That SACK block means "I have received bytes 19905043 through 19915122 and I expect 19915123 next."
I guess this explains the behaviour I saw, what do you think?
You are correct. The receiver had received all segments through sequence number 19903602, and it was asking for the segment beginning with sequence number 19903603. It had also received the segments containing bytes 19905043 through 19915122. Once the segment with beginning with sequence number 19903603 was received, that filled in the gap from 19903603 to 19905042. The segments containing bytes 19905043 through 19915122 had already been received and reported, so the receiver now began asking for the segment beginning with sequence number 19915123.
Even though that SACK block 19905043-19915123 was no longer being listed in the header because of the header size limitation, it had already been reported. The receiver had already received those bytes, and the sender knew (because of the SACK block) that those bytes had already been received.
| | 2 | No.2 Revision |
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.
There is no rule in TCP directly limiting the number of SACK blocks that can be present in the TCP header, but there is a rule that limits the size of the TCP header to 60 bytes, which indirectly limits the number of SACK blocks that can be present. If no other options are present, there can be up to four SACK blocks. If other options are present, there will be less room for SACK blocks, which is why you never saw more than three SACK blocks.
The client was asking for the segment 19903603-19905043 (1440 bytes);
It's more accurate to say that the receiver (client) was asking for the segment beginning with sequence number 19903603. The client doesn't know how many bytes are in the segment until it is received.
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
Now my question is: where did the client take the seven segments that it acknowledged?
I have to add that, at the beginning of the Dup ACKs, the segment 19905043-19915123 was tracked in the client's SACK, before being flushed out by newer 'TCP segments not captured'
That SACK block means "I have received bytes 19905043 through 19915122 and I expect 19915123 next."
I guess this explains the behaviour I saw, what do you think?
You are correct. The receiver had received all segments through sequence number 19903602, and it was asking for the segment beginning with sequence number 19903603. It had also received the segments containing bytes 19905043 through 19915122. Once the segment with beginning with sequence number 19903603 was received, that filled in the gap from 19903603 to 19905042. The segments containing bytes 19905043 through 19915122 had already been received and reported, so the receiver now began asking for the segment beginning with sequence number 19915123.
Even though that SACK block 19905043-19915123 was no longer being listed in the header because of the header size limitation, it had already been reported. The receiver had already received those bytes, and the sender knew (because of the SACK block) that those bytes had already been received.
