MUSIC] Good day viewers. In this segment I'll tell you about the transmission control protocol. And yes, this is it, this segment is about TCP and how it works, the one you've been waiting for. Tcp implements steams transport service. That's accessed by sockets. And it's the protocol that's used to transfer the vast majority of content that's used on the internet today. So all of these devices implement TCP as well as IP. Okay, here are some of TCP's features. I'm going to go through some of them a little bit. However, you're already in a position to understand the bulk of them because they use the concepts that we've worked up to at this stage. Tcp provides a reliable bite stream service. I'll talk a little more about what that means. That's the service interface. In terms of implementing it, that service is implemented using connections, okay? We know how they work, how we set them up and tear them down. The reliabilities provided with a sliding window that uses an adaptive timeout. Check, we've seen how that works, the sliding window and an adaptive timeout. I'll tell you some of the TCP specific details of it though. Tcp also includes flow control to help slow receivers handle fast senders, well we've seen how that works too. So these are the features that I'll cover just very briefly in this segment. We will next time later on we'll also look at another topic, congestion control, which is implemented by TCP. This is to match the sending rate of the sender to the available capacity inside the network. This is a major portion of TCP, but we're going to treat it as another topic just because there's so much there. So really I'm mostly talking about reliability functions today. Okay so this Reliable Bytestream model. In a Reliable Bytestream model, as you've surely guessed, message boundaries and not preserved between send and received calls. So the, the bytes that are sent down from the sender, they are delivered to the other side reliably and in the same order. So that when you read them, you get what you would expect. But the units in which they're sent down, there're no message boundaries that are preserved. Just as an example of that you can see here the sender is sending makes 4 calls to send and it sends half a kilobyte with every call. So two kilobytes sent to the network. On the other end of the receiver, it would be possible to make a single receive call and receive all those 2 kilobytes at once. Depending when they came in, and when the timing of the calls, what the timing of the calls was, this is what I mean by message boundaries are not preserved. It's really a stream of bytes that we're sending from one side to the other. A reliable bytestream also gives us another opportunity to combine things. This bytestream is bidirectional, so we're able to transfer data in both directions. Because of this, on segments TCP segments, that are sent in the network, we can piggyback control information going in one direction, with data that's been sent in the opposite direction. Control information is informational acknowledgement number for instance. So as you can see here, there is a data segment that's been sent from a to b, it's carrying information. That's great. As well as that, it's also carrying here a little bit of control information, ack numbers for the reverse stream of data that's being sent from b to a. That's the packet down Here. And similarly, that segment down there is also carrying control information, the ACK, for data that it has just run in the reverse direction, from A to B. So these segments are combining information from both directions, it's called piggy back Backing, it's quite clever. So what we'll do just to see a little bit of TCP, is we'll look at the TCP header. This is a good way to see the features of protocols. Here's the header, shown in this picture here. First up, it has ports. These identify the apps, which are using the transport service. We talked about ports previously in, with, when we covered the socket API. Here in the head of ACK is 16 bit identifiers. Okay, well next comes the sequence of acknowledgement numbers. These are used to implement the sliding window. Tcp uses a selective repeat style of sliding window, and the Sequence and ACK number really carry our byte positions rather than segment numbers. So that's one difference right there. I can tell you a little more about this sliding window, just in terms of how TCP implements it. The ACK that comes back is what is called a Cumulative ACK. It tells us the next expected byte number in sequence. So if you like according to our terminology this is just LAS+1. It's telling us the next part that's expected. In addition, and optionally, TCP acknowledgements can contain selective ACKS. And these are some of the hints we mentioned, sometimes used with selective repeat. That try to tell the sender what's going on at the receiver in terms of its buffer state. Set blocks in TCP can specify up to 3 byte ranges that have been received beyond the cumulative ACK. So ACK its going back from B to A might for instance say, Hi I'm an ACK and I'm Acking up to all bytes have been received up to a byte 99 in the next byte I expect is a 100, that's a cumulative ACK and in addition to that I also have [unknown] to have received. Bytes a 100, I'm sorry bytes 200 to 299. So you can see there's a bit of a hole here. We don't know what happened to bytes 100 to 199 yet. At the sender, TCP uses an adaptive time out strategy. Retransmissions based on this adaptive time out, to resend the data. When the timer goes out form the, from the highest acknowledgment nubmer the next expected byte onwards. However, and this is the cliver bit that TCP. Tcp uses a vairiety of heuristis to infer loss quickly. So that it can resend the data and avoud thsee timeouts. And it does that by using information in the ACK stream. There is a three duplicate ACKs rule of thumb that's used to find loss. Now, what's that all about? Let's see an example and I think it'll become clear. Okay so here is an ACK going back. This is just the first ACK for ACK 100. Suppose, next we get an ACK for 100 again that's a duplicate ACK. Now our cumulative ACK has not moved, so we've sent the same value again, and in addition maybe we get a SEQ block saying, oh, not only have I got up to 99's where I expect 100, but I've also gotten 200 to 299. Next ACK, number three. That's a, another accumulative ACK, because it says the cumulative ACK is now, still at 100. But oh, looks like I've received some new data. It was just further out. And finally there is the 4th ACK here, or the 3rd duplicate ACK, says I'm still at 100 but I've now got also bytes 200 to 499. Well at this stage you don't have to be a genius to think to yourself, well I guess that bytes 100 to 199 have just been lost, that's what happened, that explains this hole. The sender uses this heuristic to decide that, that data range has been lost, and resend it, hopefully before the timeout goes off. Three duplicate ACKs is used as a little bit of tradeoff, because we don't actually know for sure if that packet is late in the network or lost. It could've been late just because it took a slightly different path through the network. So waiting for three duplicate ACKS provides a little bit of robustness against some packet reordering. And you can also see here, by the way, that if I simply had the ACK numbers, and none of this, this ACK blocks, I could also make the same guess. That the next thing beyond a 100 that's probably what was lost in sender, so TCP uses heuristics. We'll see a little more about it when we get to congestion control because this overlaps that subject. Okay, so what else is in this header? Well not to much actually. You can see here there is some flags that are used to set up connections. These are the syn and the fyn flags. And there's also a reset To abort. These are simply flags because these messages also reuse the sequence numbers and acknoledgement numbers. For instance, to set up a connection with a sin, the sequence number here is used as a parameter, instead of having to carry elsewhere in the pra, packet. And there is also a window size you can see if it's used for flow control. Like c connect, this is measured in bites rather than segments. And this is the number of bi, bites above the space remaining. Or units above the space remaining relative to the value of the ACK. Okay, so that's it in our quick tour of TCP. Now it turns out that there are many, many quirks with TCP, that you can learn about if you study TCP in detail. But in some sense, these are all in the details. We've gone over the main ideas so that you should be able to understand how the sliding window connections and flow control, the key bits of TCP work. The only bit we haven't really talked about, which is key to the functioning of TCP, is congestion control. And that's a subject we'll get to in the next unit.