 So, some quick questions about TCP flow control. Just try and write the answers, try and think about them yourselves, don't discuss them. Just try and think about the answer so you can judge whether you understand what we covered yesterday. First question, and each question uses the same network, so we'll see the picture of the network. Here we have a path through our internet, from one computer, a client, to some server, some other computer, and we want to focus on sending data. You can write in your lecture notes, just try and do any calculations on your own. I will not ask you to submit, but you can check your answers later. So here's a network, and there are some routers in between the client and server, and the links have some characteristics between client and server, some data rate and some delay, note that this is the one-way delay, and the links have the same characteristics in both directions. What's the round trip time? Easy to get started. Try and work it out in your head first or on a piece of paper, and then we'll ask for answers. What is the round trip time for client to server? Between client and server. Anyone not have an answer? Okay, so I'm still calculating, fine. What is the RTT round trip time? Okay, everyone's had enough time, answer first. Now whenever you give an answer in a quiz, but especially in an exam, always think about units as well, always give an answer when relevant with units. If you say five, do you mean five hours, five kilobits per second, five bar? So again, anyone with an answer? I hear numbers. Twenty milliseconds. Twenty milliseconds, okay? Twenty milliseconds is the answer. Round trip time, time to get there and back. So from client to server, these numbers given here, one millisecond, five milliseconds are the one-way delays, one-way, one direction across that link. So to send from C to the first router takes one millisecond. First router to second, router five milliseconds. So that's six milliseconds so far, eight, ten to get to the server. And in this simple case, it's the same to get back, another ten to get back. So to send one packet from client to server and get a response back takes 20 milliseconds. That's the round trip time. Now, in reality, the delay depends upon other factors like the size of the packet we send. If I send a small packet versus a big packet, there'll be a different round trip time. But approximately in most networks, in practice, usually it's about the same. There's not much difference due to the size of the packet because the main factors may be the delays in routers as well. But in this simple case, we just assign delays to links. 20 milliseconds to get there and back. Question two, same network, so it's the same network diagram in all these questions. If UDP is used to send data from client to server, what's the maximum throughput that can be achieved? Given the information we have, so ignoring other things that are not specified like headers and frame structures, UDP is used as a transport protocol. I'm sending a large file from, I'm transferring a one gigabyte file from client to server. What's the maximum throughput you think we can achieve? Not TCP, UDP. Don't waste too much time copying the questions, just try and answer them. I'll give you these slides later, I'll post it on the website. Anyone, five megabits per second? Why is it five megabits per second? The bottleneck link, okay? In a path, in general, when we have a path made up of multiple links with different data rates, the speed at which we can transfer that data across that path is limited by the smallest link data rate, what we call the bottleneck link. In this case, five megabits per second is the bottleneck link. UDP, with UDP, what happens when we transfer data? What protocol, what mechanisms do we use to transfer data if using UDP? Sliding window, no, we don't use sliding window. We just keep sending, we have no retransmissions with UDP. There's no things like flow control that we discussed yesterday with TCP. There's no congestion control. With UDP, we just send our data, send packets. In theory, with UDP, we can get the higher performance than TCP, because TCP has other features like flow control and retransmissions and congestion control that may slow down our sending rate and eventually our throughput. Whereas UDP, we send as fast as possible. Assuming nothing is lost, then we will receive the data as fast as we send. And the limit in this case is the bottleneck link, five megabits per second. So if there are no other overheads taking into account, we'll get a throughput of five megabits per second transferring that data. In reality, the throughput of sending our one gigabyte file will, we need to also calculate the impact of header sizes, the size of the ethernet header, the size of the IP header and so on. But for simplicity, we'll approach five megabits per second with throughput. What if it changes to TCP instead of UDP? Five was the answer there. We'll come to that in the next few questions. We'll do what happens if we use TCP. But before we get that, what is the bandwidth delay product of the path? Bandwidth delay product. Everyone try and think of their answer first and then we'll ask. So here's a path in our network. What is the bandwidth delay product of that path? And just as we go, I'll keep a record of some of our answers. Our answers from before round trip time with 20 milliseconds, UDP throughput, five megabits per second, bandwidth delay product, 100, be careful with the units, 100 kilobits, kilobits, 100,000 bits. Bandwidth delay product is measured in, is a measure of size of information, bits or bytes, for example. And bandwidth is, think of the path rate, which we actually used in the second question. The UDP throughput was limited by the bottleneck of five megabits per second. Same when we calculate the bandwidth delay product, the bandwidth really is the path data rate, the speed at which we can send. The delay is the round trip time. So it's our five megabits per second, the limited speed, multiplied by the delay, a round trip time of 20 milliseconds. Five by 10 to the power of six times by 20 by 10 to the power of minus three is 100 by 10 to the power of three, bits, 100,000 bits. So 100,000 bits or 12,500 bytes if we want to convert. Now coming back to the question, what if we're using TCP? How big should the server buffer be to achieve maximum TCP throughput? So now I want to get the best TCP throughput possible. We know something about the network. The server needs a buffer for it to receive data. How big should it be? Assuming we're sending data from client to server. That's a lower case, correct, okay. How big should the server buffer be? We need to allocate some memory, a buffer space at the server for this TCP connection. Okay, the server buffer needs to be greater than or equal to the bandwidth delay product, which we calculated as 100,000 bits. So recall, with TCP, in fact I should have qualified a bit. We're focusing just on the flow control aspect. We're not considering data loss. We're not considering congestion control, which we haven't even spoken about. But with respect to TCP flow control, the TCP flow control mechanism allows us to send some data, and then we have to wait for an act. We will achieve maximum throughput if we can continuously send data, not having to wait for an act. How much data are we allowed to send? It's controlled by the server. The server, based upon its buffer, indicates how much data we're allowed to send. So if the buffer is empty, then we're allowed to send enough data that fills up the buffer. So if the buffer is 100,000 bits, then the client is allowed to send 100,000 bits, and then it will have to wait for an act. But what the bandwidth delay product tells us is that we'll get an act just as we finish transmitting that 100,000 bits. And therefore, as soon as we get that act, we're allowed to send more bits, and we'll spend no time waiting. So as long as the server buffer is larger than the bandwidth delay product, under normal conditions, if there's no packet loss and so on, then we'll be able to continuously transmit our data. So the answer is greater than 100,000 bits or 12,500 bytes, whichever unit you want to use. It can be greater, it can be the same. So in short, the server buffer should be greater than or equal to the bandwidth delay product. If it is, quickly draw it, we get this scenario of we send 100,000 bits, and when the act for the first packet comes back, then instead of having to wait, after sending that 100,000 bits, we get the act and we're allowed to send more. And we'll get another act and we're allowed to send more. We'll always be able to send. If we had a smaller buffer size, then we'd be limited to be able to send and then wait a little bit for the act to come back, and we wouldn't get maximum throughput. So maximum throughput can only be achieved if the buffer size is greater than or equal to the bandwidth delay product. And that's an important part for TCP performance. Because normally, we know that the characteristics of the network, the path affixed, we cannot control them. But we can control the server buffer size. We can set it large enough such that for the bandwidth delay product, we'll get maximum throughput. Related question. What if the server buffer was 6,000 bytes? What would we get? What throughput? If the server buffer is 6,000 bytes. So the server buffer has 6,000 bytes of space. What's the best we can achieve with TCP? Again, give you units. Throughput, we measure in bits or bytes per second. Either one is. Again, about half of the original. What's the exact value? OK, maybe you need to calculate. So fair enough, about half of the original. Let's see how we calculate it. The server buffer size is 6,000 bytes. Assuming as data comes into the buffer at the server, the server application removes it immediately, then recall what happens with TCP. When we send back an AC, the server indicates the window size, which is the available space in the buffer. The remaining space. What's the maximum window size that this server can send back in the AC? What's the maximum value of the window field in the TCP AC? 6,000. OK, if the buffer is 6,000 bytes, the window actually measures bytes, not bits. If the buffer is 6,000 bytes, the server sends back an AC saying how much space I have available. The maximum we can say is 6,000. Sometimes it will be less, but there's never going to be more than 6,000 bytes available in the buffer. So as we receive data, we put it into the buffer, and as the application of the server processes that data, it removes from the buffer. So the maximum we can send back is a window of 6,000. The window is what limits how much this client can send. So if the window is 6,000 bytes, it means the client is allowed to send 6,000 bytes before waiting for an AC. So let's say we send 6,000 bytes in multiple segments, but 6,000 bytes of data in total. We send that and then we have to wait for an AC. How long does it take to transmit 6,000 bytes? Well, with our path rate, we have 5 megabits per second. So the time here, the time 6,000 bytes, multiplied by 8 to get the bits, and the average rate at which we send is our 5 megabits per second, 5 by 10 to the 6. We're not calculating at the moment. That's how long it takes to transmit. How long does it take to get the AC back? How long does it take to get the AC for the first segment back? No. How long does it take? We send one segment. How long does it take to get an AC back? Total. 20. The round-trip time. I send a segment. I get an AC back. The round-trip time tells us how long. So this time is our round-trip time of 20. 20 milliseconds. In fact, what's the value of lowercase t here? The calculator will help me. It is, what is it? 48,000 divided by 5 million is 9.6 milliseconds. So the time to send our 6,000 bytes is 9.6 milliseconds. The time to get the AC back for the first segment, which means we're allowed to send more, is 20 milliseconds, the round-trip time. And then we'll be able to transmit some more. And we'll keep receiving ACs back. And usually, well, as we receive ACs, we'll be able to send more, and we'll be able to send another 6,000 bytes. Then we'll have to wait. And we can keep doing that. So over time, every 20 milliseconds, we're sending for 9.6 milliseconds. What's the efficiency in that case? Sorry? Okay, 48%, 0.48, or 9.6, so we're transmitting our real data for 9.6 milliseconds every 20 milliseconds. So we spend 48% of the time sending our data, 52% of the time waiting. So we say we're 48% efficient, or 0.48 as a fraction. About 50%, isn't it? 0.48, or 48%. Efficiency we can represent as a fraction or as a percentage. And then throughput is easy. Throughput, we have some data rate, our 5 megabits per second, and the throughput divided by the data rate is the efficiency. Or we can calculate throughput as efficiency multiplied by the data rate. That is, we have a 5 megabit per second path, 48% of the time we're delivering the real data. So the throughput is 48% of 5 megabits per second, which is, what is it, 2.4 or something? About half of our 5 megabits per second. 48% of 5 megabits per second. For sure, you can calculate it in different ways, but you'll get the same number. That is, I've gone the long way to calculate this. But you notice, and I think what you noticed before, that our desired buffer size was 12,500 bytes, or 100,000 bits. That we calculated before gives us the optimal throughput. Here we have about half, or 48%, and as a result, the throughput is 48% of what the maximum is. So 6,000 divided by 12,500 is also 0.48. But the mathematics is the same. It's just some different cancellations. You get the same number. So in brief, the throughput is the... What do we get here? This is buffer size divided by data rate, divided by round trip time, and then multiplied by data rate. In summary, the throughput is the buffer size divided by the round trip time. So when we don't get the optimal, we can calculate easily the throughput. If you look at the mathematics there, the throughput is the buffer size divided by the round trip time. 6,000 bytes divided by 20 milliseconds. 48,000 bits divided by 20 milliseconds is 2.4 megabits per second. And it's the same mathematics as just... You can cancel out the data rate. Buffer divided by round trip time. Or advertised window size divided by round trip time. I think in some of your handouts you see that. The advertised window, this value, which depends upon the buffer size, increase the buffer, and we increase our throughput up to some maximum. Once the buffer is up to 12,500 bytes, we'll start to get 5 megabits per second throughput. And we can't go any higher than 5 megabits per second. 2.5. Why did I say 2.5? There's a mistake there. I changed the answer, but I didn't change the question. Here's 50,000 bits. Our question was 48,000 bits. So the answer here should be 48,000 bits, or 6,000 bytes, and the answer is 2.4 megabits per second. So there's a mistake in my slide here. I was going to change it to make it a nicer value. So the question is, if it's 6,000 bytes or 48,000 bits, the answer is 2.4 megabits per second. And it questions on these basics of TCP flow control. They're important when we want to analyse the performance of TCP. So really, we've found round-trip time, bandwidth delay product, and that tells us the desired size of the buffer at the server. If we have a smaller buffer, we can calculate what throughput we'll get. It'll be less than maximum. Efficiency is what percentage or what fraction of time we spend delivering the real data. We look at this diagram. Not so clear any more, but every 20 milliseconds, every round-trip time, we're delivering 6,000 bytes, or we're transmitting real data for 9.6 milliseconds. Because to send 6,000 bytes, it takes 9.6 milliseconds, because 6,000 bytes at 5 megabits per second. So how efficient are we using our link, or our path, to deliver data? Our path supports 5 megabits per second. What percentage of that am I using to deliver real data? Well, the other way to look at it, I'm sending for 9.6 milliseconds every 20 milliseconds. Not to scale here. 9.6 divided by 20. Efficiency of 0.48. 48%. Or the other way around, if you knew the data rate, 5 megabits per second, and I gave you the throughput, was 2.4 megabits per second. Easily, the efficiency is 2.4 divided by 5. Efficiency is throughput divided by data rate. What is... Lowercase t. That's just the time, the data transmission time. The time to transmit the data. This not throughput, the time to transmit this 6,000 bytes. I have 6,000 bytes of data to send. How long does it take? Well, 6,000 bytes divided by the data rate of 5 megabits per second. Transmission time. This is stuff everyone knows. Transmission time. Data size divided by data rate. 6,000 divided by 5 megabits per second. That's the transmission time. Transmit for 9.6. And then wait for 10.4 milliseconds. And then transmit again for 9.6. Wait for 10.4. On average, we're transmitting 48% of the time. Any more questions before we get on to the more fun stuff? Fun stuff. Let's try and move from some concepts and theory. And let's try and move into what happens in practice and see how this will work on two computers. So we're going to... a few questions to explain some concepts of what happens in practice. And then we'll give a demonstration through the handouts I gave you yesterday. Same scenario. Now, so before I ask you to understand that, we see that the buffer size impacts on TCP performance. Given a path which has a round-trip time and some path rate, given that to increase the TCP throughput, we need to increase the server buffer size. So if we can control the server buffer size, we can control TCP throughput. How do we control the server buffer size? Well, when you start a TCP connection, you can set the size of the buffer. And it works differently with different software and different operating systems. I'll demonstrate with a Linux operating system because it's easy to find the values or I know the values. Basically what happens in Linux, when an application opens a TCP connection, it's got the option to set the amount of memory to allocate for that connection. So when the application starts on the server, it can specify how much memory that it wants for that connection. Except it's a little bit more complex than what we've seen so far. What happens is that when your application starts, and here's an example application, IPERF, you use that in the assignment. You have an IPERF client and an IPERF server. The IPERF server, you start with the minus s option. You can pass another option, the minus w, which specifies the window size that is to be used by the server. And it will be used by the operating system to create a buffer of a particular size at the server. So what happens when IPERF starts on the server with the minus w 20,000 bits, what IPERF the application is doing is requesting from the operating system to allocate 20,000 bits for my received buffer. The operating system doesn't always listen, or actually it needs to create a bit more space. So here's my server. We run IPERF on the server. IPERF requests allocate 20,000 bits for my buffer. What the Linux operating system does is allocates double that of memory for this TCP connection. So the application requests 20,000 bits. The operating system allocates 40,000 bits. I won't say buffer here, I'll say memory. 40,000 bits in our example are allocated. In fact, that's the answer to the question here. So we're just using this question to explain a new concept. Now, in Windows and other systems, it may be different. So we're just going through one specific example here. The operating system allocates double what the application requests. Why? Well, the idea is that the application wants some data for the buffer, the data that's received. But the operating system must keep some data structures as well to store that data and to keep track of the data. So in Linux, the operating system by default allocates double of what the application wants. So it's got enough memory for both the data as well as other data structures the operating system must store. The operating system has some data structures to keep track of the ordering of that data, something about the connection and so on. So it allocates double. So there's 40,000 bits of memory allocated in this case. The application requested 20,000 bits. The OS allocated 40,000 bits. Now, the important thing is how much of that memory is used for storing data? How much is the buffer? We've got 40,000 bits of memory. How much is used for the received buffer for our data? And again, it depends upon the configuration of your operating system. Some part is used to receive data, which what we called in the previous as the received buffer. And the other is to store operating system-specific data structures. That doesn't help TCP, not the throughput. We want to know how big this is. And again, it's complex. It depends upon the setup of your OS. In older versions of Linux, it was 75% of the total. If we allocated some total number of bits by the operating system, 75% was reserved for data. The remaining 25% was reserved for OS-specific storage. In other words, 75% is the TCP received buffer. 25% is other stuff. We don't really care about the other stuff. So in the example that we had on the board, if the total was 40,000 bits, because IPERF requested 20,000 bits, the OS allocated 40,000 bits, 75% was the buffer. In our case, 30,000 bits. That is, the TCP received buffer is 30,000 bits. And that would impact upon our throughput. So when we calculate the TCP throughput, we'd need to use this number as the buffer size and the advertise window. I'm trying to introduce this because we'll need it to understand the example. And it's important to realize that some of the things we talk about in the lecture from a conceptual or theoretical point of view, when it comes to the details and implementations, it's much more complex than what we cover in the lecture. The concepts are the same, but there are finer details in real software and real hardware. So just one example, if the operating system allocates 75%, if IPERF requests 20,000 bits, the OS allocates 40,000 bits in total, but 30,000 are used for the TCP received buffer. It was just the defaults for the OS. You can change those defaults. So make sure you understand. If we want to get... I want to run IPERF on my server and I want to get maximum performance in the network that we had in our previous questions. When you start IPERF, what value are you going to give here? And the hint, remember, our bandwidth delay product is 12,500 bytes or 100,000 bits. To get maximum throughput, our received buffer needs to be this size. But now, if we deal with the details with Linux, when we start IPERF, the application on the server, what value do you set for the minus W option? Show me the answer. Don't tell me. Let the others calculate. In bytes? Yes. Correct. Anyone else? So now we're coming to practice. What if you want to run a test using IPERF? What value are you going to use for the minus W option? Minus? You give the answer in either. In fact, with IPERF, you can specify a modifier K or whatever. Bits or bytes. If there's no prefix, then it's in bits. You can specify in bytes if needed. So recall what happens is the IPERF requests some value. The OS doubles that value to make some extra space for the other storage. And then, in this case, 75% of the total is used for the received buffer. And we need our received buffer to be greater than or equal to our bandwidth delay product. Anyone else get an answer? Just some simple mathematics. Primary school mathematics here. Feel free to use a calculator quickly because I want to go through a demo and we're running out of time. We take the W value, whatever we specify here, multiply by 2. That's what the OS does. It doubles it. And then 75% of that is available for TCP. Three quarters. And we need that to be equal to a larger than 100,000 bits. We require a value of 100,000 bits or 12,500 bytes. That's what our buffer size should be. That application requests this. The OS doubles it. And then three quarters of that is allocated to the TCP received buffer. So solve for W, 66,000 bits. So just a peculiarity of how the Linux operating system deals with this. That's, in fact, that's explained a bit in the handout that we'll go through. In the last six months or so, the Linux operating system, the default, has changed. And I only found out yesterday when I was trying to set this up. No longer is it 75% for the buffer. In most recent versions of the operating system, the kernel is now 50-50. It makes life a little bit easier in our calculations. What do we need now? That is, Iperf requests some value, W. Operating system doubles it. And then 50% of the total is reserved for buffer. That is, 50% of the total is the TCP received buffer. The value doesn't change. So if we request 100,000 bits, the TCP received buffer will be 100,000 bits. So it's a little bit nicer to deal with. So the answer here is 100,000 bits. Same. 100,000 bits. Operating system doubles it to 200,000 bits. But now 50% of that is used for the real TCP buffer. And 50% of 200,000 is back to 100,000 bits. And that's what we need, 100,000 bits. You can change these values of how it splits up. But the default values now, I think, at least on my computers, are 50-50. Let's try. So what I'm going to go through in the next 30, the remaining 30 minutes is this handout I gave you yesterday and try and demonstrate on these computers. And measure the TCP throughput. And some of the things we do, I'll show you, will be useful for your assignment. So just watch and follow on the handouts. Where are we? So what I'm going to do is I've got two computers, both running Linux. I'm going to connect them direct using a wired LAN interface. And then I'm going to use TCP to transfer data. In fact, I'll use IPERF. We'll measure the throughput. And then we'll change the buffer size of the receiver and see how that impacts on the throughput. So I'm going to set up my simple network. There's disable networking here. And set the IP address on my plug-in, my LAN cable. And set the IP address. So my Lenovo computer here is 1111. And the other one I've set to 1112. And let's just ping and see if it's working. No. There's a rule or an unwritten rule in the entertainment industry that you don't work with animals or children. Because when you work with animals or children, they do something unexpected. Movie or TV never turns out well. Same in teaching. I have a written rule, unwritten rule, that do not give experiments in lectures because they never work. But we'll try and we'll see how it goes. I see the mistake. I set the wrong address on the blue one. Let's set it to 1112. You cannot see what I'm doing on the blue one, but it's effectively similar to what we've done here. Okay. Ping across our wired LAN. And let's note, what's the round-trip time about? Ping tells us the approximate round-trip time. We see it varies, but it's about half a millisecond. So we see the round-trip time across our simple network here. Half a millisecond, plus or minus a bit. What's the data rate across our network? Well, anyone want to guess? What's the data rate? 100 megabits per second. With Ethernet link between two computers, it depends upon the fastest speed supported by each LAN card. The DH tool shows us some information about my Ethernet link, and it shows me that the speed of my link is 100 megabits per second. So, because my blue laptop only supports up to 100 megabits per second. So our rate? 100 megabits per second. Bandwidth delay product? We just multiply those two together. What is it? 100 by 10 to the 6 by 0.5 is 50,000 bits. So in that case, the bandwidth delay product is 50,000 bits. I want to change it. I can do experiments with this, but let's try something different. I want to... Sometimes we'd like to create some different conditions. So, what I want to do first before I run some experiments is I want to increase the round-trip time. Just so that I can create some values which I can control and a bit nicer to calculate with. So, the round-trip time depends upon the link speed, the packet size, and the processing delay in my computers, which is very small, and we see a round-trip time of about half a millisecond. What I want to do is artificially... I want to introduce some artificial delay inside my link. Let's try and increase the round-trip time to, let's say, 10 milliseconds. And this is a program that may be useful in your assignment. Normally, when you send a packet in your computer, there is no delay that that packet is transmitted, and the only delay of processing is what your CPU delays it. But what we can do is we can use software to introduce an artificial delay into that packet. Normally, when you transmit a packet, when the packet is created, it's transmitted. I'm going to use some software such that when the packet is created, it's held for some period of time, say, 5 milliseconds, and then transmitted. Let's add an extra delay to each of the packets before we transmit them. And because there will be an extra delay, it will take longer to get to the blue laptop, and then we'll actually add an extra delay to send one back so that the round-trip time is larger than our half a millisecond. So this is to create or to simulate a network which has a larger round-trip time. The program I'm going to use is called TC, Traffic Control. And it's quite complex. I can't remember the syntax. Let's type it in and then explain. I want to emulate some extra delay in the network. And let's make it... What do we have? We had half a millisecond. I'm going to add about 4.7 milliseconds on this computer, and I'll do the same on the other computer. What this command does, Traffic Control, it controls data coming out of your computer. And when the data comes out of your computer, before it's sent, it's put in a queue. Put in a queue and then send. Normally, as it arrives in the queue, it's just sent immediately. So long as there's nothing else to be sent. What we're going to do is change the queue discipline here. And for my Ethernet zero device, I'm going to emulate this net emulator network where there's an additional delay of 4.7 milliseconds. A packet is created inside my computer. It's put inside the queue. It is held in the queue for 4.7 milliseconds and then sent. That means each packet will have an extra 4.7 millisecond delay. That's what TC will do. I'm going to do the same on the other computer so that this is only for packets being sent. So when my source computer sends packets, every packet will have an extra 4.7 milliseconds. And when I respond with packets, we'll get the same. You cannot see this, but it's exactly the same command. And I'll also add 4.7 milliseconds. And I've done that. And now let's ping. Note the round-trip time. Before we had a round-trip time of half a millisecond, I've introduced this artificial delay of 4.7 on one computer, 4.7 on another computer, which is a total of what? 9.4 milliseconds plus the original half a millisecond. And it brings us to a total of about 10 milliseconds. So I chose the 4.7 so that the total is about 10 milliseconds. And we will use that in our experiment. Round-trip time now is 10 milliseconds, nicer number, bandwidth delay product, 10 times 100 a thousand a million bits, 10 milliseconds by 100 megabits per second. We have a bandwidth delay product of a million bits, or what is it, 125,000 kilobytes? 125,000 bytes. TCP measures in bytes. So sometimes it's useful to give the bandwidth delay product in bytes. So I just used TC to introduce some arbitrary or artificial delay into the network, just for this experiment. The other thing I'm going to do, and I'm not going to explain right now, because we may run out of time at the end, normally when you send packets, if you've got a large amount of data, TCP will break it into smaller segments, and individual segments will be sent. Nowadays with the LAN cards, rather than TCP inside the operating system breaking that data into smaller segments, which happens in software, because that can be slow, that is the software takes time to do that, instead of breaking into segments, some special operations are performed such that the hardware LAN card breaks it into segments. I will not attempt to explain that. Maybe next week we'll explain that. What I'm going to do is turn off that feature. It's described in the handout, but with limited time, let's not try to describe it any further yet. We see that there's some special features of my LAN card, which TCP segmentation offload, generic receive offload. I want to turn them off once on. The generic receive offload, GRO, let's turn it off. I want to do it on my other computer as well. I'll turn them off on my other computer. Let's move on so we can get some results. Let's now do an IPerf test and see what performance we get. I'm going to start my server, and then on the client I will connect, and let's see what we get for performance. I've started the client on the blue laptop connecting to the IPerf server, and it runs for 10 seconds. What do we get? 93.8 megabits per second. There's our throughput for our TCP connection. Now let's go back and see why we get that and see what happens when we change the buffer size of the receiver. What buffer size did we use in that test? What's the normal buffer size that TCP allocates? Well, in fact, it gives us some hint here. When we start IPerf without any options, TCP window size, 85.3 kilobytes, that's the default value. Let's try and set it to some values and see what happens, and then we'll do some calculations and check whether it makes sense compared to what we've been just talking about. Now, to set it to some values, so to set the buffer size at the receiver to a particular value, there are two different ways. We can let the application do it. IPerf, we can use a minus W option and set it to some size. Or you can do it at the operating system level so that the default value, when we don't specify a value, will be whatever we choose. First, let's see what the operating system has as a default value. So the operating system chooses the buffer size unless the application specifies. To see the current value, we need to look at an operating system parameter. In Linux, the parameters are stored in files and we can use the program called SystemControl to look at these parameter values and to even change them. And the parameter, if I can remember the value, the name, TCP is a network parameter using IP version 4, TCP received memory, rmem. This is the default values that TCP allocates for the received buffer. In fact, there are three values shown. rmem, the received memory. That's what the operating sets. There's a minimum value of 4,096 bytes, a maximum value of about 4 megabytes and the default value of 87,380 bytes. And note when IPERF started without any option, when we didn't use a minus W option, we said IPERF reported the TCP window size, the default 85.3 kilobytes. In fact, IPERF, the K kilobytes here is 1,024 bytes. So K in IPERF represents 1,024, not 1,000. So 1,024 times by 85.3 is 87,380 bytes. So the operating system allocates 87,380 bytes for the TCP received buffer. That's the default value. In fact, it's a little bit more complex than that in that the Linux operating system may automatically change this value. Depending upon your network condition, the round-trip time and the throughput or the data rate, the operating system may change this value anywhere between the minimum and the maximum. It's got some automatic tuning technique where it will vary this value to try to give best performance for you. For my experiments, I want to turn off that capability. I want to set it to a fixed value. I don't want the operating system to modify it. So to turn off this automatic tuning, it's another parameter of the operating system called TCP Moderate Receive Buffer. This is some feature of the operating system that automatically chooses the window size. And it's set to one which is currently on. I'm going to turn it off. You shouldn't on your computer unless you're doing experiments. Set it to zero. So now it doesn't automatically tune. Now whenever an application starts, opens a TCP connection, the server will allocate 87,380 bytes always unless the application specifies a different value. We can even use system control to change these values. So you can change these values at the operating system level. Let's use iperf to change the values. Make sure everything's update and check my other computer. Our bandwidth delay product is a million bits, 125,000 bytes. In fact, when we specify a value in iperf, this is the server, so we set the receive buffer using the minus w option. We specify in bytes. Let's try a value of 50,000. So I'm setting the receive buffer or the application is telling the operating system to set the receive buffer to 50,000 bytes. Now, remember what happens. The application requests 50,000 bytes. The operating system allocates double that, 100,000 bytes. iperf even tells us that. iperf says warning. I requested 50,000 bytes. Now, be careful. iperf reports here k is this 1,024, not 1,000. So 1,024 times 48.8 is 50,000 bytes. You requested 50,000, but the operating system allocated 100,000 or 97.7 times 1,024. So this is just iperf warning us that the operating system has done something different than what we requested. Let's run the client. I'm starting the client. Why did I get a throughput of 37 megabits per second? Try and calculate. What's the expected throughput? So I just did a test. I got a throughput, an actual measured throughput of 37.0 megabits per second. Why? What would you expect? The round-trip time of our path is 10 milliseconds. When I started iperf at the server, I set the TCP or requested 50,000 bytes for the window or buffer size. Recall what happens is the operating system doubles that to 100,000 and then 50% is allocated for the true received buffer, back to 50,000. So the TCP received buffer is 50,000 bytes. The buffer for data, which is what TCP flow control is based on, is 50,000 bytes. What do you expect the throughput to be in that case? 40% of... which is a throughput of... you're correct. 40 megabits per second. Remember throughput is... well, first, are we going to get maximum throughput? TCP received buffer is 50,000 bytes. Are we going to get maximum throughput? Yes or no? Compare this to the bandwidth delay product. To get the maximum throughput, we need at least the bandwidth delay product as the buffer size. Our buffer size is 50,000 bytes. Bandwidth delay product is 125,000 bytes. We're not going to get maximum throughput. Our received buffer needs to be larger than the bandwidth delay product. What throughput are we going to get? Well, easy. It's the received buffer size divided by the round-trip time. We'll be able to send 50,000 bytes every round-trip time, every 10 milliseconds. 50,000 bytes is 400,000 bits divided by 10 milliseconds. 40 megabits per second. That's what we expect as a throughput. 40 megabits per second, which is 40% of our 100 megabit per second data rate. What do we actually get? 37 megabits per second. Why are they different? Why didn't I get 40? Overhead. When we say 40 megabits per second, that doesn't take into account the fact that when we're using IPERF, there are headers included in every packet. And how much? How big is each header? Let's draw it over here. From memory. If this is every packet, what happens is that we have many header fields. We have some data. We have a TCP header. We have an IP header. TCP header, when we use IPERF, you can check, but I think it's around 32 bytes. IP header is 20 bytes. We have an Ethernet header, which is 14 bytes. And then, in fact, Ethernet, so that's our Ethernet frame. At the end, there's an Ethernet checksum, a CRC checksum. And now I'm starting to guess there are around 4 bytes. It's a 32-bit checksum. And when we transmit an Ethernet frame, so what we do is on the link, I create an Ethernet frame, transmit it. There's some extra time which is used by the physical layer effectively before we transmit to synchronize the signal. And I cannot remember the value. It's around 8 bytes. So what we do is we transmit this Ethernet frame and then we wait a little bit of time and then we transmit the next Ethernet frame. And we continually transmit these Ethernet frames. The amount of time we wait it's in the order of 10 bytes. And the data in Iperf, and you have to check this in the capture, is around 1,430 bytes. Now some of these numbers I'll have to check but just from memory. What Iperf reports is the throughput of the data. It doesn't count the headers and this extra time. So it's approximately 1,430 divided by the total which is plus 52,66 78, 88. We have extra header which introduces an overhead and it's approximately about 94%. What that means is when we transmit data using Ethernet my Ethernet link supports 100 megabits per second the best I'm going to get because of headers is about 94 megabits per second. 94% of the maximum. What we calculated here of 40 megabits per second is what we expect without headers. We'd expect about 94% of that. The real throughput. Whatever that is 94% of 40 is 37.6. So what we calculated here of this 50,000 bytes divided by 10 milliseconds of 40 megabit per second throughput we have to consider also the headers and it's approximately 94% that is 6% overhead so the throughput that really Iperf is going to report should be around 37.6 megabits per second plus or minus a little bit. What do we actually get? Well 37, that's close enough. So that's very close to what we expect. One last test last minute let's change the window size at the receiver what value do you want to see? Let's do let's try 100,000 what throughput do you expect? Start the client you've got 10 seconds to answer receiver window 100,000 bytes throughput quick with 77 double okay should be about double because before we had 50,000 bytes throughput is buffer size divided by 10 milliseconds now we've gone up to 100,000 bytes we're still not at the bandwidth delay product we get 77 megabits per second let's change it again let's make it 125,000 what are we going to get? should be close to 100% but consider headers should be headers of 94% throughput of 94 megabits per second okay 93.9 megabits per second one more 200,000 what are we going to get? 200,000 is the window size we should get the same that is we can't go above 94 megabits per second our link rate is 100 megabits per second plus take into account headers which takes about 6% of that the best we're ever going to get is 94 megabits per second and that's what we get no matter if we increase the server buffer size a million bytes 10 million bytes will always be limited to this 94 megabits per second or the maximum throughput so we see with these simple tests changing the receiver buffer performance too small and your throughput is much less than what you expect you need to set it at least to the bandwidth delay product to get the maximum throughput we're out of time for today so you can follow through and see the rest of the details on that handout those people who weren't here yesterday can have this last copy and next week we'll move into TCP congestion control which is another part of how TCP or the impacts on TCP performance enough for today