 So TCP is the transmission control protocol. It's a transport protocol. So I always return to our five layer stack, which we use for our model for internet communications, a way to break the different features for communications into parts organized by layers. At the bottom two layers, we have the technologies for dealing with getting data across a link to sending signals using the physical layer and then making sure the bits are delivered correctly across a link. So wireless LAN, for example, Ethernet, ATM, a lot of the network technologies we introduced in the first lecture fall within these two layers. So dealing with individual links, but of course in the internet, we want to join many different networks together. And that's the role of the network layer. And the core protocol is IP, the internet protocol. IP allows us to send data across multiple different networks even though they're using different data link and physical layer technologies, the networks, the hosts, and the routers are all using the internet protocol IP at the network layer. So that joins all our networks together. At the top, we have protocols which are for specific applications. For example, for web browsing, there's one type of application. There's a protocol we commonly use, HTTP. I've just listed a few here, HTTP for web browsing. When you use an email client and send an email to an email server and the email servers deliver that email, there's SMTP, the simple mail transfer protocol. When you log into another computer, there's SSH, Telnet, and others. And many different application layer protocols. We don't have to remember them all. You use some of them on a regular basis. Those protocols are designed for specific purposes, for web browsing or for email. Because they have different requirements, therefore we use different protocols. So IP gets data across the network, across the internet. Then we have protocols for specific applications. But many of these applications have similar requirements in delivering data across the internet. In particular, most of them, and the four that I listed here, plus many others, need reliability, which means if we send something from my computer to a server, I want to make sure that that data gets to the server. If I send a one megabyte file, the server must receive that exact one megabytes. Because in the internet, and in links, we may have errors, then we need some protocol to provide this reliability. When I'm web browsing, I need reliability. When I'm sending an email, I need 100% reliability. That is the exact email must be delivered to the destination. And many other applications need reliability. Rather than implementing the reliability mechanisms in individual protocols, we have a separate protocol, TCP, which fits at the transport layer, which provides reliability plus other features for any of these application protocols that need it. So if we want to reliably transfer a web page from its client to server, do not implement that reliability feature inside HTTP. Instead, use TCP, which already has it for us. It means that these application protocols are much simpler in that they don't have to focus on reliability. They can leave that to TCP, which does it on their behalf. And it's not just reliability. We'll see that TCP offers it some other services that provide our applications. So we're going to spend some time going through how TCP works. What's the other transport protocol commonly used in the internet? Give me another transport protocol. You should be the answer in your final exam, because you're a Simon, again. UDP is the other primary transport protocol. There's two main ones, TCP and UDP. UDP is very, very simple in that it simply takes data from the application and sends it to IP. It doesn't provide reliability, and it doesn't provide many of the features that TCP provides. We'll see what TCP provides, and I'll mention which ones that UDP does not provide. It's only needed what's used when we need a very simple protocol, and sometimes when we focus on performance. There are several others which are quite new, which are not so common compared to TCP and UDP. We're focusing on TCP in this topic, because most of the internet applications we use make use of TCP. Not all, but most. So when you're downloading a file from some web server, one aspect that controls the speed of that download is how TCP works. When you send an email, when you're web browsing, using FTP to download files, using secure shell to log into terminals, then TCP impacts upon how that data is transferred, and especially the performance in some cases. So we want to understand how it works and how it impacts on performance. So what I'm going to do in this topic is we're going to introduce some basic features. But everyone knows TCP, correct? Everyone remembers, even the EC students have probably covered parts of it in their courses. I'll give a quick reminder of some of the features. We're not going to go through all the features. We're going to go through two new features that maybe most of you have not seen. So a bit of a review. And then we're going to spend, you'll see a lot of these lecture notes are focused on congestion control, which I don't think anyone or very few of you have seen how it works in TCP. But before that, just to make sure everyone's at the same level, we'll go through another feature of TCP flow control, which are not in these lecture notes, but I'll give you some others when we get to that. But first, a quick review. I've said this. It's the most commonly used transport protocol today. Some of the features or services it provides to the application protocols. Let's talk about the ones which are easier to understand first. It's a connection-oriented data transfer protocol. What that means is when I want to send data, before I send data, I establish a connection from client to server. So I want to send data from my laptop to some web server using TCP. Then there's some procedure to first contact the server and say, I want to transfer data, and the server agrees, and then we send the data. So we establish a connection first. Some of you will remember a TCP three-way handshake. You send a SIN, SINAC, and AC. That's the way to establish a connection. We will not cover that in any more detail of this course. It's considered an end-to-end protocol. I don't think it says it here, between end points, maybe. End-to-end protocol, TCP operates between client and server, hosts. The routers in the internet don't play any part in TCP. So when I contact the Facebook web server, the TCP software on my laptop is communicating with the TCP software on the Facebook web server. The routers all the way between us in the internet have no role in how TCP works between the end points. So it's called an end-to-end protocol in that only the end points use it. Whereas the internet protocol IP is used at the hosts, the end points, and the routers along the way. Skip down. It's a full duplex connection. So we establish a connection from client to server. And one of them initiates that connection establishment. My client normally initiates to contact the server. But once the connection is set up, I can send data to the server using that connection. And the server can send data back to me. So that's why we call it a full duplex connection. Data can be exchanged in both directions. What else have we got that's a bit easier to understand? It provides reliability. And I think everyone knows the basic mechanism for providing reliability is retransmission. What you do is you send some data from A to B. And if B receives that data successfully, it will send back an acknowledgement saying, thank you. I received that data. If it doesn't receive the data, then, of course, no acknowledgement will come back. And hence, the source after sending the data waits some time. If it receives the acknowledgement, everything's OK. If it doesn't receive an acknowledgement within some timeout period, it assumes that the data has been lost or there's been an error. And therefore, retransmits that data. So we use positive acknowledgments in that we send data and we receive a positive act back. And if we don't receive an act within some time, retransmit our data. And there are some details of how that works, but that's the basic mechanism. And that's an ARQ scheme, an automatic repeat request scheme. So I think all of you have probably heard of stop and wait ARQ and sliding window or selective reject and go back NARQ, TCP makes use of similar schemes. We'll see a quick example of that, but not too many details. The concept is quite simple. What else? TCP sends a stream of bits, or maybe better to think of bytes, between endpoints. What that means is, when I establish a connection from my client to some server, and I say my application has 1,000 bytes to send, my application sends it to TCP, TCP may send that 1,000 bytes across the internet, or it may wait and send it a little bit later. And if my application has another 500 bytes to send, then TCP doesn't distinguish between the first 1,000 and the second 500. It just treats that as 1,500 bytes. It doesn't treat it as two different messages, and send the first one and then send the second one. It can in fact take the first 1,000, join it with the second 500, and send them all together as one. So we say TCP operates on a stream of bytes. From TCP's perspective, it doesn't care whether there's 1,000, 1,500, it doesn't distinguish between them. It's just a continuous stream of bytes. And what may happen, in fact, is that my application has 1,000 bytes to send, and then a little bit later, 500 bytes to send. Together, those 1,500 bytes get sent across the internet. The application that the receiver receives all 1,500 at once, because, again, TCP doesn't distinguish between the different messages. We will not see too many details about that. It will not impact on what we study much, other than the way that we see sequence numbers. And that some of the examples we'll see is that we give sequence numbers to the data that we send. We send the first piece of data, sequence number one, the second piece of data, sequence number two, and so on. As we send more data, we increment the sequence number. So we can keep track at the receiver what order we receive the data. In TCP, those sequence numbers count bytes. If I send 1,000 bytes, the first byte we can think is sequence number one. The 1,000th byte is sequence number 1,000. And the next 1,000th first byte is 1,001 as a sequence number. We'll see some examples of that shortly. What else? The buffered transfer is like the example I just gave in that my application may send 1,000 bytes to TCP and then another 500. TCP may buffer that, store it in memory, and send it all at once to try to improve the network performance. I'm not sure if we'll see many examples of that. TCP has one type of segment. Even though I said with reliability we send data and receive an act, in fact, it's just a TCP segment. There's no separate segment called an act. The segment has a header, which is normally 20 bytes. We can include some options to make the header larger. By default, we assume it's just 20 bytes, no options. And then has some data. The fields in the header include the source and destination port numbers. These are numbers that identify the applications at the client and server. My web browser, when it establishes a TCP connection to a web server, my web browser has a port number, usually chosen by my operating system. And the web server has a port number. And the port number is 80. Web server port number typically uses port number 80. So servers commonly use fixed port numbers. Clients may use random or dynamic port numbers. Again, we will not study too many details about the port numbers. You may have seen in other courses. You just may see them in some examples that we go through. When we send data, we give that data a sequence number and include that sequence number in the header. When we send back an acknowledgement, we send back an acknowledgement number in the header, which indicates the next sequence number we expect to receive. If I send sequence number one, the receiver sends back an act with acknowledgement number two, saying thank you for sending me number one. I now expect the next number, which is two in the sequence. They are the main fields that we'll see or make use of in this course and other things that we have. The header length is just an indicator of how long our header is, which is important if we include options, because it would be larger than 20 bytes. Reserved are not used. There are some flags. The flags are just one bit values. When the bit is binary one, it means that feature is on. The flag is up. When it's zero, the feature is off. The flag is down. And they are used to indicate the meaning of this message. The two, actually on one of the next slides, the list of flags is given. Now, one bit values are listed here. The important ones we'll see in the topics we cover with TCP really are the act flag. When we send a TCP segment, if it contains data but no acknowledgment, then usually all the flags will be off, will be zero. But if we want to send an acknowledgment, an act, we set the act flag to be on. And there are some other flags for different purposes. A checksum is used at the receiver to check if there are any errors in the received segment. Urgent pointer is used for special cases if we want to make sure some data is delivered quickly or urgently. And the last thing, and again this will be important in the topics we cover, is a window. A 16-bit field which we'll explain the purpose of when we look at flow control. So remember when we come back and describe that the header, every TCP segment has a 32-bit sequence number. It optionally, when the act flag is set, has a meaningful acknowledgment number. When the act flag is not set, the acknowledgment number has no meaning and has a 16-bit window field. We'll refer to them shortly. So what does TCP do? Four main features. It allows us to establish a connection before we send data. Some of you know how that works. We're not going to test or examine in any detail of how the connection establishment works in this course. We're going to focus on the data transfer. Once the connection's established, how do we send data? Which is the next three features. And these three features are the main ones that impact on our performance of TCP. What throughput do we get when we use TCP? Reliability. It uses a retransmission scheme in that we send data and we expect to get acts back. If we don't get acts, we have a timeout. And if we timeout, we retransmit. There are some options, and I'll show you the options or the variations of the retransmission scheme. The aim is to make sure all the data is delivered to the receiver with no errors. And in particular, in order. If I send three sets of data, then it needs to be delivered in order at the receiver, one, two, and three. It should not be rearranged between the sender and receiver. So reliability is the main feature. The other two features, and that's what we're going to focus on in this course, are flow control and congestion control. And these are making sure that when we send data into the internet that we don't cause any problems in the internet. The first one, flow control, is making sure we don't cause problems at the receiver. We do not overflow the receiver computer. So if I'm sending to a server, that server has some processing ability. If I send too fast, I may overflow the memory at that computer causing problems and packet loss. So we're going to go through how flow control works. The aim, remember, make sure the sender doesn't send too fast such that it overflows the receiver. So we'll explain how that works. And then we'll explain congestion control. And that is making sure that the sender doesn't send too fast such that it doesn't overflow the network, which mainly is the routers. So if I draw our simple internet, we have our sender, our TCP sender, and a receiver computer. And they're connected via some set of routers in the internet. The sender sends data to the receiver using TCP. Without flow control, what could happen is that the sender sends data. And it sends it as fast as possible. It may happen that the receiver is slow. And as it receives the data, it must store it in memory in some buffer, which is a limited size. And as it receives that data, if it's coming in too fast, it will have to start dropping some of that data. That is overflowing the memory at the receiver. If that happens, if we start to drop data, we'll have to retransmit, which causes drops in performance, especially throughput and increased delay. So what flow control is about is making sure that the sender doesn't send too fast such that it will not overflow the receiver. So we'll cover how that works. Congestion control is about not overflowing the routers. Similar, the routers have buffers. As they receive packets from our sender and also from other senders, of course, there's more than just one sender in the internet, they have buffers or memory. And as they receive packets, as packets come into the router, the router puts them in memory and eventually sends them out across the next link. And as does this router and all the routers. If we send too fast, and everyone sends too fast, it's possible that a lot of packets come into the router. The router only has a fixed amount of memory to store them. And therefore, it cannot send them out fast enough, and packets will start to be dropped at the router. So if the input rate to the router is greater than the output rate, the rate that it can send, then some packets will come in, be stored in memory. And once that memory or the buffer in the router is full, the next packet that comes in cannot be stored. Something must be dropped, discarded. And as a result, the data doesn't get to the destination, we'll have to do a retransmission, which is bad for performance. So congestion control is a way to make sure that the sender doesn't send too fast such that it overflows the routers in the internet. Avoid congestion in the internet. And it's a key part of how the internet works today. So what we need to go through, you'll see the slides of focus on congestion control. But in fact, I'm going to go through flow control first, because I think maybe not everyone is seen flow control. Reliability, I'll say a few things about just quickly. But I don't have the slides with you, or you don't have them. Here's a handout with a few extra slides. And these are from ITS 323 last semester. So some of you may have seen them already or remember them. Just one sheet, six slides on that one sheet. So some slides to talk firstly about the basic way that reliability is implemented and a little bit about flow control. So six slides here about how data transfer works in TCP. I think we've said this before, at least that TCP has mechanisms for flow control, error control, congestion control, and reliability, which is error control, controlling what happens when we have errors. And it has separate algorithms for each of them, although some of them are related. So we can sometimes discuss them separately, but later we'll see there's some relationship between them. We're going to look at the general algorithms for those three. In fact, in some cases, the details of how they work depend upon the implementation. So one operating system may implement it slightly different than another operating system. So some things are not specified and we cannot predict in advance. TCP uses a sliding window mechanism. What that means is that we are allowed to send multiple chunks of data before having to wait for an acknowledgement. And we'll see that when we look at the flow control. We've said this before, I think, treat messages as a continuous stream of bytes. That's nothing new. So we need to go through this. This is an illustration of how sequence numbers work in TCP. Our source computer, our sender computer, the application has some data to send to the receiver. So the application in this example has 10,000 bytes to send from A to B. A is the source computer, B is the destination computer. 10,000 bytes to send. The application delivers that to TCP inside our sending computer. And the way to think of how TCP uses sequence numbers is that it allocates each byte of data a sequence number. And it doesn't have to start from 0 or 1. It can start from some other value, which was negotiated when we set up the connection. It's called the initial sequence number. So before we send any data, we establish a connection and choose an initial sequence number. In this example, and just in this example, I've set it to 300. What that means is that of this 10,000 bytes of data, we can conceptually think that the first byte has sequence number 301. The second byte would be 302, 303, and we'd number every byte such that the last byte would be 10,300. 10,000 bytes from 301 up to 10,300. That's only for the case where the initial sequence number is 300. That initial sequence number is chosen when we set up the connection, so it would be different each time. This data is stored in some buffer, some memory inside our computer that TCP has allocated, ready to be sent to the network layer and eventually cross the internet. TCP decides how to send that data, that 10,000 bytes, in that it may not send it all as one packet across the internet. It may send split it into multiple chunks. And those chunks we call in TCP segments. And that's depending upon the implementation of TCP. So depending upon how much data, the exact timing at which it was received, determines how big the segments will be. In this rather trivial example, I've decided to, or my TCP has decided to break this 10,000 bytes into four segments. And I just chose the segment sizes so that they're different, but easy numbers. I chose such that it breaks it into four chunks of data. The first two contain 1,000 bytes, and the second two contain 4,000 bytes. In reality, it may not do this. It's such an even break that the size would depend upon different factors, but just to demonstrate how sequence numbers are worth. So that's the top diagram. So what TCP does is creates a TCP packet, or normally called a TCP segment. So the chunk of data that TCP sends is called a segment. And it takes that first 1,000 bytes of data. It attaches a TCP header, normally 20 bytes of header, to get our TCP segment. Segment number one. And inside the header, there's the sequence number field. And the value of that field is the value of the first sequence number of the data inside that segment. So in the first case, the first byte, sequence number 301. Therefore, in the first segment, header value has sequence number 301. In the second segment, which contains bytes from 1,301 up to 2,300, because the first 1,000 bytes are from 301 up to 1,300. Then we go 1,301, 1,302 up to 2,300. Then the header of the second segment has sequence number 1301, which is the sequence number of the first byte. And we continue for the other two segments. So the sequence numbers included in the header are the sequence number of the first byte of data, where each byte of data gets an increment. We increment the sequence number by 1. So some people get confused. We think of sometimes segments as segment 1, segment 2, 3, 4. And maybe then sequence number 1, 2, 3, 4. Well, no, that's not how TCP works. TCP works in that the sequence number counts bytes. So sequence number 301, 1,301, and so on. So the sequence number will depend upon how many bytes are contained in the previous segments. Each of these four segments are then sent as IP datagrams. So TCP sends a segment to the network layer protocol in your computer. IP creates one IP datagram, sends it across the link, and out into the internet. Then the next TCP segment. So in fact, there will be four segments and four IP datagrams sent across the internet. And those four datagrams should arrive at the receiver. And if everything's OK, the receiver will receive the four, put them back together so that we get the original 10,000 bytes. And how does it know to put them back together in the right order based upon the sequence numbers? That's the basics of how sequence numbers work. It's not my intention to explain in the details of this, it's just so that when we see the examples later that you can make sense of the examples, because we'll see some of these sequence numbers in the examples. Some of you have covered this before and no problems. Or it's just a reminder, others may not have covered it. So any questions before we move on? Have you covered this in Dr. Somsuck's course? You guess. OK. No, the sequence number count the data. So h here is the TCP header, is 20 bytes. So the length here, of course, includes the header, but the sequence number included in the header field, the number counts the data only. Here's an example of a very simple case of the data transfer. And it's for those four segments that we just created, the first one, sequence number 301, and then 1301, 2301, 6301. And it's just showing a diagram and just to introduce some of the terminology we may see in some of the pictures. I said before, there's only one type of TCP segment. There are not different types of segments, but often we distinguish based upon the meaning of the segment. So here I've drawn, this is a TCP segment being sent from A to B. And I've called it a data segment in that it contains data. It contains 1,000 bytes of data. And in brackets here I've included the sequence number to say this is a data segment, and the sequence number is 301 in that data segment. B receives that data. And in this simple example, B sends back an acknowledgement saying thank you, I've received the data. And again, it's a TCP segment, but the AC flag is set, and so I call it an AC. And the way that the AC is used is that the acknowledgement number indicates the next sequence number expected. Let's just go back to our packet format. Note that there are two numbers in a TCP header. Sequence number and acknowledgement number, AC number. Sequence number is used when we're sending the data. So it counts the data being sent. The AC number is used in the opposite direction when we are acknowledging data that's been received. So the number in brackets for the data segment is the sequence number, whereas the number in brackets for the AC segment is the acknowledgement number. And here we send the second segment, get an AC, the third segment, AC, fourth segment, AC. If I had a fifth segment, let's draw it, had a TCP header, had some data. Let's say it was 2,000 bytes of data in the fifth segment. Here I've drawn just four segments. What would you draw here if we followed the same operation? So if we continued and drew the next exchange of data, that fifth segment being sent from A to B, what would the sequence number be? Try and determine the sequence number of a fifth segment. This fifth segment contains 2,000 bytes of data. What's the sequence number if we come after 10,301? It's easy in this case in that remember the AC that comes back indicates the next number expected. So here we're going to send 10,301. If you go back to the previous diagrams, we would see that remember that the first byte was 301. The last was 10,300. Therefore the next, the header has sequence number 10,301. And that's successfully received at B and B sends back an AC. What is the AC number? 12,301. The sequence number of this segment is 10,301. There are 2,000 bytes in there. So conceptually, you can think the first byte is 10,301. The second byte is 10,302, 10,303. If you keep counting those bytes, the last byte would be what? What sequence number? 12,300. If we start at 301, 302, the last byte would be 12,300. Are you going to play some music for us? Then I'll forgive you if you do. The last one is 12,300. And therefore the AC that comes back says thank you. The next one I expect is 12,301. So the AC number always says the next number. Not the last one received, the next one expected. That's the simplest example of data transfer in TCP. And as we have more data to send, we can keep going. And it questions on the use of sequence numbers in TCP. This is a very simple example of how the ACs work and that there's a data AC, data AC. It doesn't have to be like that. A, we don't have to have an AC for every data segment. We could have one data segment, multiple data segments received and just one AC coming back. And the ACs may not come immediately. That is, we may not get the first AC before we send the second piece of data. We're allowed to send multiple data segments. Let's look at the basics of error control. TCP uses a selective retransmission style of ARQ in that we can send data segments. We expect ACs to come back, if not retransmit. Selective retransmission is a case where we may send multiple segments of data. We get some indication back that there's been an error. Maybe one didn't arrive at the destination. So we retransmit that one selected segment as opposed to retransmit multiple segments. Let's look at how it works. Again, a simple example. Here, the diagram's a little bit different in that I did not draw the entire frame to make the simpler on the picture. What I draw is, here's a case where there were six segments sent by A to B. And in TCP, it uses a sliding window mechanism, which allows it to send multiple segments before it has to wait for an act. So it sends the first segment, the second segment, third, the sixth segment. Those segments take time to get to the destination. Remember, between A and B is the internet. So the time to get there may vary. So instead of waiting for an act to come back before we send the second segment, in TCP, we're allowed to send multiple segments. And then we wait for an act. So in this example, the first two segments arrive OK. When B receives them, they send back an act. In this case, every segment has 1,000 bytes. So simply data1, act 1,001. Data 1,001, act 2,001. That's the next number expected. The third segment is lost. Something goes wrong in the internet, and it doesn't get to B. Of course, B doesn't know that. It's just waiting to receive segments. When B receives the fourth segment, in this case, it sends back an act. But note that the acknowledgement number is the same as the previous one. B sent back act 1,001, because it's received up to 1,000. Then it receives the next 1,000 bytes, so it's expecting 2,001. It receives the fourth segment, but importantly, the receiver expects to receive the data in order. It's received 2,000 up to 2,000, but it's waiting for segment with sequence number 2,001. But that didn't arrive because it was lost. So in this case, it sends back an act saying, I still want to receive 2,001. I haven't received it yet. And it receives segment 5. I'm still waiting for 2,001 and segment 6. From A's perspective, we can think whenever it sends a segment, it starts a timer. And that timer, when it reaches some predefined timeout value, it triggers a retransmission. So with the first segment, we start a timer. If we receive an act before it times out, then we stop the timer and that segment's done, success. But in the case of the third segment, we send it, we start our timer, we're waiting for an act. We're waiting for an act. We should receive an act saying act number 3,001 because the third segment contains number 2,001 up to 3,000. We should receive act number 3,001. We're waiting. We haven't received act 3,001. We've still received act 2,001. Waiting. Our timer expires. That triggers us to make the assumption that the data was lost. And when the data's lost, we will try again. So we retransmit that third segment. And in this case, it arrives at B. And now, what B can do is send back an act indicating it's now successfully received all six segments, indicating act number 6001. Because B has received the first two segments, it receives segments 4, 5, and 6. It was missing segment 3. But then segment 3 is retransmitted. B receives that, so now it has 1 through to 6 and sends back an act number and would now be expecting the next segment. There are many details of how that works in some different cases, but that's the basics of how retransmission works in TCP. It's going to become important when we look at congestion control. You remember how it works from last semester? No problems? You answered the question in the final exam last semester. The important point is that, as with most retransmission schemes, we send data. We wait for an act. If we don't receive an act within a timeout period, we can't retransmit. TCP only requires us to retransmit that one loss segment. And we've seen that allows the sender to send multiple segments before waiting for an act. That's the sliding window mechanism. And to control all that, that's what the sequence numbers are used for. The problem with retransmissions is that we can be inefficient in using the network. Look from A's perspective. It's sending it six segments. That's good. Then it spends a lot of time waiting before it sends something else. That is, a lot of time not sending. And if it's not sending, we're being inefficient because we're not using our network if we're not sending anything. Why are we not sending? Because we've sent our six and we're now waiting for an act. And we'll wait until the timeout occurs. If we have a long timeout period, then we wait a long time and it can be inefficient in delivering the data. There's an optimization of this retransmission scheme that allows us to retransmit often before a timeout occurs. The problem is normally the timeout period needs to be quite large. How large should it be? What should the timeout period depend upon? In this case, how long should the timer be for our TCP source? How would you calculate or determine what a good value for the timer would be? Round trip time, what is that? What does it depend upon? Latency of what? Latency is some delay of what? Time to do what? Time to send the data, time to receive an act. So something about the time to get our data to be and get an act back. Because when we send our data, we must give the receiver enough time to receive it, process, and send back an act. So the timeout period should be greater than that time. It should be greater than the time it takes us to send the data to be. The data propagates through the internet. Get to be, process by be, and then be, send back an act. How long is that in the internet? How long does it take to send a packet from you to a server? What's the round trip time? Anyone have an idea? What is it in the internet? It depends upon the transmission time, propagation time. What's the value? Anyone have an idea? 30 milliseconds, OK, let's take a very specific case. What if the client was my laptop and the server was my computer up in the office? The time to get there and back will depend upon the land speed, my 100 megabit per second connection. That impacts upon the transmission time and the distance, because our signal has to propagate, which is what, tens of meters. So that would be quite short. How short? Let's ping a computer and find out. Ping is a way to just make that bigger, disappeared. That's pinging from my laptop to my computer, or router, upstairs in my office. The time to get there and back is about, well, that's a bad example. Let's change something, sorry. Let's ping someone else. I've prepared my computer for some other purpose. Let me just configure my computer for this to work a bit better. One of the servers in SIT, in fact, run the IT server, the Moodle server, 10, 10, 6, 12. So this is to a server. It's in the other building. The server's over the third floor of the other building from my laptop. The round trip time is about 0.8 milliseconds. Less than 1 millisecond. So in this case, if I'm using TCP, the round trip time, the timeout period should be larger than this 1 millisecond or so, slightly larger, give us a bit of room. What if I ping or connect to the Facebook web server? Is it going to be the same? Is it going to be more? What if I connect to a server inside Thailand? Is it going to be the same as the Facebook web server? My examples are not working well because we can't ping inside SIT. What can I do? Unfortunately, SIT blocks pings, so let's try a different example. Let's get a better example, which gives us some different times. Here's a server which allows us to ping. The source here is in Japan. Let's zoom in a bit. So let's ping somewhere in Japan. This is the Google website in Japan. It's taking 11 milliseconds, approximately, to ping from some server in Japan to another one in Japan. I can't remember the cities of the destination. One's in Tokyo. So 11 milliseconds. Remember, from my laptop upstairs was less than 1 millisecond. So there's a difference there. If we ping from the sources in Japan to, let's say, TU, somewhere in Thailand, 125 milliseconds. So the source in this case is in Japan. The source is in Japan. When we pinged another computer in Japan, it was 11 milliseconds. When I ping the TU web server in Thailand, from Japan to Thailand, 125 milliseconds. And if you try different destinations, you'll get different values. I'm not sure if it'll respond. Facebook, 180 milliseconds. It depends upon different factors. It depends upon the propagation delay and the transmission delay, as well as queuing delay. So it depends upon the link speeds between source and destination, the distance between source and destination, and the routers between source and destination, especially if they're overloaded. Our ping may be delayed along the way. So normally, the further you are, the longer it will be. So inside Thailand, it should be short. Between countries, it will be larger, depending upon the countries. Time to leave is different, as well. Let's go back to the point we're trying to make, is that the time from one computer in the internet to some other computer varies depending on where they are, what network they're on. So coming back to TCP, what value do we set our time out to be? So that's our problem that we have. With TCP, the time out period should be slightly larger than the time it takes to get there and back. But the time it takes to get there and back varies from less than a millisecond to hundreds of milliseconds. So predicting the best value for the time out is quite hard. And generally, we make it larger than we actually need. The problem with a large time out period is we spend a lot of time waiting before we retransmit and can be very inefficient. So waiting for a time out to force a retransmission can lead to bad performance in TCP, which leads us to optimization called fast retransmit. Note in the basic retransmission scheme, what happened in our case, B receives the first two segments and says, I'm waiting for 2001. I expect to receive sequence number 2001. It doesn't receive it. It receives something else, in fact, 3001. It's still waiting to receive 2001. So sends back an act saying so, saying, I'm still waiting for 2001. And as it receives the third segment, I'm still waiting for 2001. Sorry, this is the fourth and the fifth one it receives, 2001. The source A can use this information to give an indication that probably something's gone wrong. And that's what the fast retransmit does. Exact same scenario, 6 cent, third one lost. B does exactly the same. But what A does now, A receives act 1001. OK, everything's OK. Act 2001, still everything's OK. I expected that. But then it receives act 2001 again. A has sent data segment 2001. And it receives act 2001. Well, that's an indication maybe my segment with sequence number 2001 hasn't arrived yet at B. And then I receive another act 2001. That gives me more confidence that the segment I sent here hasn't arrived at B. And a third act with the same number is the first one here. And at that point, we make the assumption something's gone wrong. I know I have sent 2001. I've now received four acts saying, I haven't, or saying that B hasn't received 2001. Let's assume 2001 was lost, so let's retransmit. Send 2001, this time successful, get the act back. This is called fast retransmit in that we retransmit that segment normally earlier than a timeout would cause a retransmit. Compare the two, basic retransmit. We wait for the timeout to occur and then retransmit. The problem is we may have to wait a long time. What, if we have a large timeout, what will more likely happen is we may receive duplicate acknowledgments. And the rule is in fast retransmit, if we receive four acts with that same act number, or it's commonly referred to as three duplicate acts. This is the first act, 2001. These three are duplicates of that first act, same act number, 2001, and then three copies of it. So the rule in fast retransmit is if we receive three duplicate acts, let's assume our data was lost, and let's immediately retransmit without waiting for our timer to expire with the hope or with the intention that we'll get the data and then we can move on to the any subsequent data. In TCP, both of them can be used, or both are used. So you send your data, if you receive three duplicate acts, then retransmit. If your timer expires, retransmit. Do whichever one occurs first. And in most cases, or in many cases, the duplicate acts will occur first. If we don't receive three duplicate acts, we still wait for the timer to expire. These two mechanisms will see that how we use them and how they impact upon our performance and congestion control is quite important. That's the end of these extra set of slides and gets us to the introduction for TCP before we go into flow control. Any questions on the basics? So retransmission scheme is we send our data. We can send multiple data segments. We wait for acts. If we receive three duplicate acts, retransmit. If we have a timeout that is our timer expires, retransmit. And we use sequence numbers to count bytes. And act numbers indicate the next sequence number expected. They are the main things to pick up on this review of TCP that's in our other slides. Let's go back to the original slides. Actually, the next thing is, the next topic is on flow control. And again, that's not in the slides that we have, but you do have a handout on flow control. It should be at the end of your lecture notes, another handout. Let's show you which one. Do you have this one? Yep. The bandwidth delay product in TCP, which is related to flow control. So we'll use some of these diagrams to explain the basics, just to introduce in the last five minutes what we mean by flow control. In fact, so I'll show some of these diagrams through the lecture, refer to this, to explain flow control. But first, let's have the simplest explanation on the board. So we have our source and destination computer connected via the internet, and TCP is running on the source and destination, the TCP software here inside the destination computer. It has some memory allocated to it. So we can think, some part of your memory of the receiver device on the computer is allocated such that when packets are received, TCP segments are received, stored inside the memory allocated for TCP. So we send the source sends TCP segments, they're sent across the internet, and they arrive at the destination. And as they arrive, they're put inside memory, TCP processes them, sends them up to the application, and then it's done. The problem arises if the speed at which the destination processes these segments that arrive is slower than they are arriving. So we're sending quickly, so we've got a fast computer here, a fast link, we're sending, many packets are arriving quickly at the destination, they arrive and stored inside memory, and TCP at the destination takes a lot of time to process each segment. So as it's processing the first segment, some new segments arrive, and that's stored in memory, and then it processes some, but more segments are arriving, stored in memory, and eventually the memory allocated for TCP fills up, because we can only allocate a certain amount, and once it fills up, what happens? When the next packet arrives, what do we do with it? Our memory is full at the receiver, another TCP segment arrives at the receiver, what's the receiver going to do? What's it going to do with that arriving segment? A queue is the memory, that is, the memory's full. We cannot put it in a queue, we cannot put it in memory, because we've got no memory left. We cannot do anything, you cannot save it. You've only got a certain amount of memory, let's say 100,000 bytes, just for this TCP receiver, you've got 100,000 bytes allocated, and it's full, it's currently storing 100,000 bytes of data. Another segment arrives on the network interface, it cannot store it anywhere, there's no more memory, so we discard either the one that arrives, or maybe even the discard one that's currently in memory, but importantly we must discard one of those segments, throw it away, it's deleted. So when our memory's full at the receiver, we discard or lose a packet, so we have a packet loss or a segment loss, and that's bad, because when we have a segment loss, eventually we'll have to retransmit. Which segment is lost depends upon the way that the receiver is set up, it could be the one that just arrived, or we could have a policy such that throw away one that's currently in the queue. If we had some way to control, to give preference to some applications, we could control which one to drop, but normally the last one, the one that just arrives, doesn't get put into the queue. Importantly, one of them is lost. We don't want that to happen, so what we do is the destination keeps track of how much space it has in its memory, and it informs the source. So if we have a little bit of space in the memory, when we send back an act, we inform the source how much space is available in the memory, and we use it, the window field in that header. For example, when we send back an act, we say we have 2,000 bytes remaining in memory using the window field, and what the source does is it will not send more than 2,000 bytes, because if destination says I have 2,000 bytes of space available, the source is not allowed to send more than 2,000 bytes, because if it sent 3,000 bytes, again, we'd get this problem. We only have space for 2,000, if we send 3,000, we can fill up the memory and we'll have a loss. So to avoid such a loss, we tell the source how much space we have available, and it will not send more than that. And as we get more space available, we keep, when we send back an act, we inform the source of how much space is available. So we use the window field in the header of the TCP act to say how much space is available in the receiver memory, and the sender maintains its sending rate such that it will not overflow the receiver. So that's the very basics of TCP flow control. We will not go through much more other than some calculations of how it impacts on performance, but you should be able to understand how that works. We'll see the details next week, and we'll use this example on the bandwidth the lay product to show some calculations.