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 video we saw that 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 complete 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 that have been sent the first segment that carries
data then 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 telling 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 acknowledgement 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 much 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 an acknowledgement 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 acknowledgement 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 that 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 number 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 just one way the error control can work there are other methods
one example 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 initializes 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 acknowledgement 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
the point is that 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 that 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 much 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 videos 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 video is good hit the like button and share it I'll see you all soon