Ask Your Question
0

Undertanding SACK and Fast Retransmission

asked 2019-08-04 05:38:20 +0000

robcar gravatar image

updated 2019-08-04 05:46:57 +0000

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 take the seven segments that it acknowledged?

Roberto

edit retag flag offensive close merge delete

Comments

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'

robcar gravatar imagerobcar ( 2019-08-04 06:04:00 +0000 )edit

From RFC 2018:

  • The data receiver SHOULD include as many distinct SACK blocks as possible in the SACK option. Note that the maximum available option space may not be sufficient to report all blocks present in the receiver's queue.

I guess this explains the behaviour I saw, what do you think?

robcar gravatar imagerobcar ( 2019-08-04 07:44:35 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2019-08-04 15:41:48 +0000

Jim Aragon gravatar image

updated 2019-08-05 01:50:40 +0000

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

edit flag offensive delete link more

Comments

Ok, thanks for the clarifications. Can we say that SACK blocks are a sort of 'pre-acks', both to the receiver and the sender? Thanks to them the sender doesn't have to retrasmit (with 'normal' retransmission, I guess) those segments, because it knows they are in the receiver's buffers

robcar gravatar imagerobcar ( 2019-08-04 21:18:42 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-08-04 05:38:20 +0000

Seen: 221 times

Last updated: Aug 05 '19