We’ve been on a journey through the transport layer looking at TCP UDP and what makes them the same, and what makes them different is the hour time for the last mile of this journey as we look at error recovery and windowing.
Data can be lost for so many reasons these errors are generally detected by the datalink protocol like Ethernet which will drop bad frames, both TCP and UDP have some error handling built in they can detect corruption by using the value in the checksum field but only TCP is considered reliable, this is because it will manage retransmission of the lost data, UDP on the other hand is considered unreliable as it will not try to recover from data loss.
to understand how this works we must first look at how the segments are acknowledged you’ll remember that when a segment is received the receiver sends an acknowledgment message confirming that it got the data in the last article, we saw there are sequence numbers in the TCP header one function of this is to reassemble the segment’s into the correct order, but they also affect acknowledgments think of the three-way handshake let’s say that the sequence number was initialized to 97 and that was sent in the syn message the syn ACK message would use a sequence of 98 and the final ACK would be 99 after the handshake is completing the meaning of this sequence number changes it won’t count the number of segments sent back and forth anymore instead now it will count the number of bytes sent the first segment that carries data than would have a sequence number of 100 as it’s the next sequence number let’s now say that this segment is 100 bytes long the server will get this segment and will need to send back an acknowledgment it doesn‘t just in the act flag though it also uses the acknowledgment field it will set this value to 200 why because it’s using a process called forward acknowledgment where it’s acknowledging the data that has been, and told the sender what it’s expecting to get next so why 200 we started with a sequence number of 100 we sent 100 bytes and now we’re ready for the data starting at byte number 200 when the next segment is sent the sequence number is set to 200 do you see how the sequence numbers track not the number of segments, but the number of bytes being transferred the advantage to this is if data went missing there would be no acknowledgment for that range of bytes the sender could then resend that range of data, but it’s not very efficient to send an acknowledgment for every single segment the sender would need to stop sending and wait for the ACK message before sending the next segment the receiver would also need to spend more compute power generating these messages so to make it more efficient TCP uses a process called windowing this allows a sender to send a certain amount of data usually over multiple segments, and the receiver can send one single acknowledgment to cover all of them the amount of data that can be acknowledged in a single message is called the window size this value is stored in the window field of the TCP header imagine that the window size is 1,000 bytes in the real world that would be larger, but we’re just using simple numbers for the example the sender now sends a segment with 100 bytes of data the window size shrinks by 100 bytes to 900 bytes there’s no need to send acknowledgment back yet as there is still room in the window the sender sends nine more 100 byte segments the window shrinks by 100 bytes each time, and when the window reaches zero the sender will stop and wait until it receives an acknowledgment once acknowledged the window size resets back to 1,000 bytes in the real world the receiver will not wait for the window to shrink to zero before sending an acknowledgment this is so the sender does not have to stop and wait for the acknowledgment which is better for traffic flow now time for a quick quiz.
do you remember what out of order delivery is how does TCP handle the situation?
after the three-way handshake completes the meaning of the sequence field changes what does it mean now and how is it used?
now we’ve covered that we can look at error recovery think of the example once again now imagine there’s a problem somewhere and the fourth segment does not arrive it’s time for error recovery to kick in the server has received nine segments, but by its 402 499 are missing it knows this because the third segment starts at byte 300 is 100 bytes long so the next segment should start at 400 but after waiting a reasonable amount of time it still does not have the segment starting at byte 400, but the server can still acknowledge the data that it has received it can send back an ACK message with 400 as the acknowledgment numbers this is saying that it expects data are starting at byte 400 next this is a really simple method of error control it’s not completely efficient as every frame from by at 400 is recent and this is a just one way the error control can work there are other methods one examples is selective acknowledgment or sak which doesn‘t need to resend all the segments right now though the important thing is not to learn all the error control messages but to remember that TCP uses error recovery and UDP does not if errors are becoming frequent TCP can adapt with the type of flow control what it will do is dynamically change the window size we’ve seen that the three-way handshake initialize values like port numbers the is n and the window size we’ve also seen that the window size is the amount of data a device can send before requiring an acknowledgment so the three-way handshake is where they agree on the initial window size but the window size isn‘t just set between two devices it’s set for each connection and each connection can have a different size each connection can change over time too which is why it’s often called a sliding window or a dynamic window okay, that’s nice and all but what’s the point is the receiver can tell the sender to send more information or less information per acknowledgment let’s think about when a connection first starts the device is at either end do not know how reliable the network path really is hopefully it’s a rock-solid reliable connection that really drops any data at all but it could also be a very flaky connection that regularly drops data to deal with this, they may start with a relatively small window size let’s say 8 kilobytes remember that this means that the sender can send up to 8 kilobytes of data before the receiver needs to acknowledge it now if this goes well they used to say if this is a reliable connection with very little or no data loss they may decide to increase their maximum window size maybe they’ll put it up to 16 kilobytes if it continues to go well they may take it to 32 and then 64 the original TCP protocol would consider 64 to be the largest window size but newer implementations can go even higher than that on the other hand what if the connection was losing data a large window size would not be good here remember that error control in some TCP implementations will resend everything from the point where data was lost a large window would mean there’s a lot of unnecessary retransmissions so instead the window will shrink data is acknowledged more often and hopefully there are fewer retransmissions a receiver could also use windows to signal the sender that’s overwhelmed it could set the window size to zero which would effectively pause the sender giving the receiver time to catch up obviously that’s not ideal, and it’s a symptom of a larger problem.
here’s an opportunity to see if you really understand what we’ve been talking about even if you don‘t want to use my answers try to use these questions to challenge your understanding we’ve seen a lot of TCP and UDP over the last few articles this will be enough for the exam but only you really scratches the surface of what these protocols can do next in this series, we’ll move from theory to practical and look at the very basics of configuring a Cisco router or switch if you thought this article is good hit the like button and share it I’ll see you all soon.