Networks are expansive, and more often than not,
we're not in control of the mediums between us and our data. Due to this,
data can go missing in action, and that's where we rely on data
retransmission to successfully complete our TCP data requests.
Retransmissions rely on sequence numbers and acknowledgement numbers.
Are you noticing a trend yet?
Retransmissions work in the following manner. Utilizing our prior robot image
example, if packets 1 and 2 were received successfully,
the next expected acknowledgement number would be 3.
But suddenly, the machine receives a 4 as its
acknowledgement number, and it goes, whoa,
hold on a second.
I'm still missing packet 3, at which point the SACK option will be initialized.
Let's drop to a quick diagram where we can see this exact process in action.
In this scenario,
the computer of 192.168.1.1 would like to download an
image once again of our super cool robot.
The web server of 192.168.1.100 replies with an ACK and
decomposes the image into sections,
at which point it sends the first section. After successfully receiving the
data, the computer of 192.168.1.1 replies with an ACK.
The second portion of the data is then sent,
at which point the requesting computer responds with an ACK once more.
At this point,
the source computer of 192.168.1.1 is expecting the next sequence number of 3.
The web server sends the third portion of data,
but it's dropped due to an unknown error with a connection along the way.
The fourth portion of data is then sent,
and it arrives successfully at the destination computer to which it
responds with an ACK. Upon receipt of the fourth sequence number, the
TCP session knows that it's missing data.
At this point, the SACK option is initialized,
and it's important to know in a non‑SACK session,
either the sender or receiver have mechanisms for
requesting data retransmissions.
But in a SACK agreed upon session, to quote the IETF RFC 2018, the receiver
is used to inform the center of non‑contiguous blocks of data that had been
received, end quote Also remember that both sides have to agree upon the
SACK negotiation, and this is completed during the three‑way handshake. With
the SACK option enabled,
it'll allow TCP sessions to continue acknowledging data while
still being able to request the missing data.
Within our scenario,
the SACK option has been agreed upon. So the source PC of 192.168.1.1
notifies the center of the missing data. At this point, the server of
192.168.1.100 retransmits the missing data. At this point,
the requesting PC of 192.168.1.1 acknowledges the receipt of the data.
The transfer is now complete.
Please understand, though, that when you're decomposing packets,
it's not usually common to deal with such perfect sequence
numbers as 1, 2, 3, 4, and so on because if we remember our prior
conversation, sequence numbers are incriminated by 1, but they
also contain TCP in‑flight data.
And remember,
we also don't ACK on every response of data. This is due to
overhead as we use window size to push as much data as we can between the devices to help cut down on ACK.