3.5-1 TCP Reliability, Flow Control, and Connection Management

[Music] in this section we're going to take a look at how a CP provides reliable data transfer and we'll see that TCP uses all of the mechanisms that we studied earlier checksums acknowledgments sequence numbers timeout and retransmit as well as pipelining and we'll also take a look at how a CP estimates the round-trip time between the sender and a receiver and how it uses that to set the timeout interval we'll also take a look at a number of tcp scenarios looking at the TCP sender and receiver in action so let's get started well as we've

seen TCP operates in a point-to-point manner that is between one sender and one receiver and the semantics of its reliable data transfer is that of an inorder byte stream and we should contrast that with UDP where we saw a UDP was message oriented what TCP implements is a reliable byte stream abstraction TCP is also full duplex meaning that data payloads can flow in both directions the data that's contained as a payload and a TCP segment as a maximum segment size of MSS and this is typically 14 60 bytes in practice but it could be any

of a number of different values as we've seen and as well illustrate shortly TCP uses cumulative acts as an go back in its a pipelined protocol it's also connection oriented which means that there's a handshake that occurs between the sender and the receiver before data actually begins to flow we'll take a look at that handshake procedure shortly and TCP is also flow controlled which means that sender and the receiver or speed match so that the sender won't overwhelm the receiver with data let's next take a look at the TCP segment structure and I know this

can seem a little bit boring and there's a lot of fields here so it may seem a little bit dry but remember the thing to keep in mind is not just what the fields are but why those fields are there and all of these cases we'll see from what we've learned already about the principles of reliable data transfer that we'll be able to understand why TCP has these fields okay so let's get started we've seen a port number and a destination port number if used for multiplexing and demultiplexing before the TCP header also contains a

32-bit sequence number and a 32-bit acknowledgement number that we're going to look at in just a second down at the bottom we see the application data that's the payload being carried by the TCP segment the TCP header also has an internet checksum just as we saw in UDP TCP also has a set of options and there's a variable number of options that could be included we're not going to go into those but that makes the header that we see here of variable length so we can carry options in a TCP header and because the header

can be a variable length we need to have a length field of the TCP header itself the reset syn and fin bits are used for connection management we'll study that shortly there's a field in the header that's used for flow control where the receiver can tell the sender the number of bytes it's willing to accept there are two bits in the header that are used for congestion notification and again we'll take a look at that later and then finally there are two bits in one field the urgent field which are not really used in practice

let's take a deeper dive into the meaning of TCP sequence number and acknowledgement number of fields here remember that TCP implements a byte stream abstraction and the sequence number carried in a TCP segment header indicates the byte stream number of the first byte in that segments payload data the acknowledgment field is used by the receiver to tell the sender the sequence of the next byte that's expected to be received from the sender and that number serves as a cumulative acknowledgment for all bytes of data that have occurred before that sequence number and lastly students often

ask what should a TCP receiver do with out of order segments the TCP specification places no requirements here that's up to the implementer so let's next look at a very simple example of TCP in action looking at sequence numbers and acknowledgment numbers in this example we're looking at a simple telnet scenario where host a sends a character to host B and host B echoes that single character back so you're going to want to take a careful look at the sequence and ack numbers on the segment shown in this example the key thing to note here

is that the act number of 43 on the b to a segment is 1 more than the sequence number 42 on the ada B segment that triggered that acknowledgment similarly the act number 80 on the last eight of B segment is 1 more than the sequence number 79 on the B to a segment that triggered that acknowledgment well we've seen that TCP uses sequence numbers and acknowledgments pretty much as we would have anticipated from our principled studied we saw that there were a couple of differences the byte stream semantics and the fact that sequence numbers

and acknowledgments correspondent to offsets in that byte stream let's next take a look at an issue we really haven't addressed yet and that is how should the timeout values be set and let's take a look at how TCP does that now clearly we're going to want the timer values to depend somehow on the round-trip time the RTT but how do we actually set that timer value if we set it to short what will happen is that we'll have premature timeouts that means that will be resending segments that have not actually been lost yet on the

other hand if we wait too long TCP is going to be slow in reacting to segment loss so a key question we're going to have to address is how do we estimate the RTT well we can actually just measure that start a timer when a segments transmitted stop the timer when an ack is received for that transmission and then we've got a simple measured RTT but as it turns out those samples can vary quite a bit from one sample to the next so what we're going to want to use is something that's a little bit

smoother an averaged value of the sample RTT so this is how TCP recomputes the estimated RTT each time a new sample RTT is taken and this process is known as an exponentially weighted moving average and it's shown by the equation here that the new value of the estimated RT T is 1 minus alpha times the old value of the estimated RT T plus alpha times the sample RT t that was just taken and this value alpha can be set to reflect the influence of the most recent measurements on the estimated RT t a typical value

of alpha used in implementations is 0.125 the graph at the bottom shows the measured RT t between a host at the University of Massachusetts and a host in France as well as the estimated smooth Rd T given this value of the estimated RT t tcp now computes the time up interval to be the estimated RT T plus some kind of safety margin and the intuition behind setting a safety margin is that if we're seeing a large variation in the sample RT t the RT t estimates are fluctuating a lot then we'll want a larger safety

margin so TCP computes the timeout interval to be the estimated RT T plus 4 times a measure of deviation in that estimated RT key value and here the deviation in the RT t is computed as the exponentially weighted moving average of the difference between the most recently measured sample RT T and the estimated RT T at that time well with our detailed knowledge of how to CP uses sequence numbers acknowledgments and the time-out mechanisms we're now in a position to summarize the behavior of both the TCP sender and the TCP receiver once we do that

we'll then take a look at a couple of scenarios showing the TCP sender and receiver in action given these details of TCP sequence numbers acts and timers we can now describe the big picture view of how the TCP sender and receiver operate you can check out the finite state machines in the book so here let's just give sort of an english-language textual description and let's start with the sender on the event that data is received from the application TCP is going to create a segment with the sequence number and send that message assuming the messages

within the sender's send window and start a timer if the timer is not already running and you may find it useful to think of there being just a single timer for the oldest unacknowledged segment how a single time or multiple timers are used is really an implementation detail on the event of a timeout the segment that caused that timeout will be retransmitted timer will be restarted and on the event that an ack is received if the ack acknowledges previously unacknowledged segments we're going to want to update what's known to be act and we'll want to

restart a timer if there are still unacknowledged segments flowing between the sender and receiver let's now turn our attention to the TCP receiver and the events that can happen at the receiver and how the receiver generates acts in response to these events well the first event that could happen would be the arrival of an inorder segment with the expected sequence number now in the case that all of the data up to this expected sequence number has already been acknowledged rather than immediately acknowledging this segment many TCP implementations will wait up to half a second for

another inorder segment to arrive and then generate a single cumulative act to cover both segments thus decreasing the amount of act traffic the arrival of this second inorder segment and the cumulative act generation that covers both segments that's the second row in this table in the case that an out-of-order segment arrives with a higher than expected sequence number there's going to be a gap that's now detected in this case remember TCP will send a duplicate act indicating the sequence number of the next expected byte and the last event is the arrival of a segment that

partially or completely fills a gap at the lower end of the receiver window in this case the receiver is going to send a cumulative acknowledgment acknowledging all data that's been received in order so far to solidify our understanding of TCP reliability let's take a look at a few retransmission scenarios in the first case a TCP segment is transmitted but the ACK is lost in this case TCP is time out mechanism results in another copy being transmitted and then re acknowledged by the receiver in the second example two segments are sent and acknowledged but there's a

premature timeout at the sender for the first segment which again is retransmitted the important thing to note is that when this retransmitted segment is received the receivers already receive the first two segments and so resends accumulative acknowledgment for both segments received so far rather than just an AK for this first segment and in this last example two segments are again transmitted the first ack is lost but the second act cumulative ack arrives at the sender successfully and so the sender can then transmit a third segment knowing that the first two segments have arrived even though

the act for the first segment was lost let's wrap up our study of TCP reliability by discussing an optimization to the original TCP known as TCP fast retransmit take a look at this example on the right here we see five segments that are transmitted and the second segments lost in this case the TCP receiver is going to generate an ACK 100 acknowledging the first received segment however when the third segment arrives at the receiver the TCP receiver sends another ACK 100 since the second segment hasn't arrived yet and similarly for the fourth and the fifth

segments to arrive now what is the sender see the sender sees the first ACK 100 this is what had been hoping for and then three additional duplicate ACK 100's arrived so now the sender knows that something's wrong it knows that the first segment arrived at the receiver but the later 3 arriving segments at the receiver the ones that generated those three duplicate ACKs were correctly received but they weren't in order that is there was a missing segment at the receiver when each of the three duplicate ACKs were generated with this fast retransmit optimization the arrival

of three duplicate ACKs causes the sender to retransmit its oldest unacknowledged segment that we see here without waiting for a timeout event this then allows TCP to recover more quickly from what is very likely a loss event well that pretty much wraps up our study of TCP reliable data transfer they hope you feel good about the fact that the mechanisms that we developed in our rdt protocols are exactly those mechanisms that are used by TCP in practice and actually we'll see these mechanisms come up again when we study the HTTP 3 protocol an application layer

protocol used by the web we're going to wrap up here by looking at two topics that are somewhat related to reliable data transfer that's flow control and connection manager you [Music]