understanding retransmission establishment

Question

Hi all,

I was reviewing the following 3 way handshake and wanted to understand what is destination host saying regarding type of retransmission. From the traces it looks like the source host is telling to use SACK while there is no answer to that from the destination.

05:29:51.675626 IP 24.6.173.220.26385 > 198.66.239.146.80: Flags [S], seq 3242633023, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
05:29:51.696997 IP 198.66.239.146.80 > 24.6.173.220.26385: Flags [S.], seq 77540153, ack 3242633024, win 57344, options [mss 1460,nop,wscale 0], length 0
05:29:51.697185 IP 24.6.173.220.26385 > 198.66.239.146.80: Flags [.], ack 1, win 16425, length 0

Can you please explain how this works?

Thanks in advance, Edmond.

Accepted Answer

1

The client announces that it knows how SACK works, while the server doesn't announce it. That means that neither client nor server can use SACK since it only works if both parties do know how. It is not "no answer" from the destination, it's just an answer that tells the client that the server doesn't use SACK.

answered 15 Jun '13, 11:32

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

So the type of ACK that the server will respond is that it supports the ACK type of the client or it doesn't, right?

(15 Jun '13, 15:01) Edmond

1

RFC 2018 describes the way SACK works. There aren't "I support these types of ACK" announcements; there are just "I support SACK, so you can use it" options. So the server will either respond with "SACK permitted" or nothing.

At least as I read RFC 2018, in the connection you show, the server could send SACKs to the client if it wished to do so, as the client says "SACK permitted", but the client must not send SACKs to the server, as the server did not say "SACK permitted".

(15 Jun '13, 16:27) Guy Harris ♦♦