 So, just a reminder, stop and wait flow control is used to make sure that the sender doesn't overflow the receiver. And the sender sends a data frame and it will only send the next data frame once it receives an act for the previous data frame. In that way, the receiver controls how fast the sender sends by sending back acts. If the receiver is busy, busy processing the data, it won't send an act until it's ready. And as a result, we don't overflow the receiver. And we saw this type of diagram that illustrates the exchange of those frames over time. So, it's a timing diagram to illustrate what happens, the events that take place. And yesterday we did a calculation for one example. We calculated for one part, we skipped over for the other two frames, so given some characteristics of the network, the link data rate, the propagation delay, the frame size. We calculated to transfer one data frame, to transfer one data frame which contained a thousand bytes of original data, it took 8,341 microseconds. And if we kept going for the next data frame, it would take the same amount of time. And we keep going forever, assuming we've always got data to send. So, if we've always got data to send, using stop and wait in this scenario, a thousand bytes every 8, 3, 4, 1 microseconds and we can calculate an efficiency or throughput in that case. We got to, well, 959,118 bits per second when we have a 1 megabit per second data rate. Or we used 95.9% of that link for transmitting original data. So that's the efficiency of using stop and wait. Let's make a couple of quick changes and recalculate, same scenario, same protocol, but let's just change a couple of values and see how the efficiency changes. What if the data frame, maybe case two, what if the data frame contains just 100 bytes instead of 1,000? So 100 bytes of data, 20 bytes of header. In the previous example, it was a thousand bytes of data, 20 bytes of header. Anything else is the same. Calculate the efficiency. A thousand bytes of data plus 20 bytes of header gives us a data frame of 100 bytes of data plus 20 bytes of header in this case, 120 bytes in total, 960 bits. So times by 8, we get 960 bits and everything else is the same. So instead of 8,160 bits at 1 megabit per second, we have 960 bits. So the transmission time of the data frame would be 960 microseconds just by changing the frame size. Everything else will be the same. The propagation delay stays the same, the act is the same size. So the act transmission time will be the same, the processing the same. That's the total time for, what's the total time for one frame transmission or one frame transfer? That is, what's this red line now that we've changed from 1,000 bytes down to 100 bytes? We made the data frame smaller. Answer anyone quickly so we can move on. Everything's the same except instead of 1,000 bytes, we have 100 bytes. So instead of 8,160 microseconds here, it's 960. So it'd be 960 plus 10 to propagate, plus 1 to process, plus 160 plus 10 is 1,141. To note the total time, T is the 960 for the data frame, plus the 10 for the propagation from the data to get from A to B, plus 1 for processing at B, plus 160 for transmission of the act coming back. And another 10 for the propagation of that act gives us 1,141 microseconds. This is the only thing that changed due to the data size changing. Throughput, we send, now assume we have, but I haven't changed anything since last lecture. Just write that from what's up from yesterday. Same scenario, smaller data size, that's all. And instead of drawing the picture, you can draw it in your own time but we can see that the total time is the data transmission, plus propagation, plus processing, plus the act transmission, plus the propagation of the act back, 1,141 microseconds. And if we keep doing that, we send the data frame of the same size, it would take another 1,141 microseconds, so we do that forever, then on average, we're sending 100 bytes of real data and each 100 bytes of real data takes 1,141 microseconds to deliver. So that gives us our throughput because everything that we send is received, which gives us, anyone calculate, how many kilobits per second? Seven, 701, someone confirm, 800 divided by 1,141, 700, about 701 kilobits per second, 701,000 bits per second, our data rate was 1,000 kilobits per second, so we can say our efficiency is 70.1%. We pay for a link that supports a million bits per second but we only use 70.1% of that to deliver our real data. Other time is we're either not sending or we're sending header. Any questions before we do another one? Questions? You can calculate this in the quiz tomorrow, the online quiz, don't worry. You may ask me, you've got it all, okay, another one then. Efficiency went down, why? The data frame is smaller, okay, all we did is change the amount of data, the same amount of header, small amount of data. Smaller data frame led to a lower efficiency when everything else was the same. Once we spend a smaller proportion of the time sending original data relative to the propagation act and the propagation back, so of the total time it's a smaller proportion sending the real data and therefore our efficiency goes down. One more case, case three, back to the original case, so back to 1,000 bytes of data, let's change instead the link distance to 200 kilometers. I think in the original question the link distance was 2 kilometers. Let's multiply by 100. If the link distance is 200 kilometers then the propagation delay will be what? Link distance is 200 kilometers, what's the propagation delay? In the previous case, link distance was 2 kilometers, propagation delay of 10 microseconds, now link distance is 200 kilometers, 100 times larger, the propagation delay will be anyone? 1000 microseconds, 100 times larger. Increase the distance by a factor of 100 increases the propagation delay by a factor of 100. Let's calculate for that case, yes? Someone calculated for me, did they calculate, correct? Where did 70.1% come from? The throughput was 701 kilobits per second, the data rate was 1 million bits per second so 701,000 divided by 1 million is 70.1%. Either ask me or be quiet, ask me now, correct? We did, no, it's the same as yesterday. Yesterday we calculated throughput first, remember throughput was the amount of original data divided by time it takes. It gives us the rate at which the original data is received. So 1000 bytes divided by 8341 microseconds gave us 959 kilobits per second. Our link data rate is 1 million. So think of, I've got a link, I can send a million bits per second but to send real data I'm only sending 959 kilobits per second. So we say the efficiency is 95.9% coming from throughput divided by link data rate. And it's exactly the same in this case, the same approach. Total time is 1141, original data is 100, throughput is 701 kilobits per second 701 kilobits per second divided by 1 million bits per second is 0.701. Correct? 701,000 divided by 1 million is 0.701, convert to a percent is 70.1%. We can express efficiency as a fraction, as a ratio between 0 and 1 or as a percent. Confirmed yet? Double check, check again. 800 bits divided by 1141, what do you get? 800 bits divided by 7.1, 701,000, 701,000 divided by 1 million, 1 million, 1 megabit per second, 1 megabit per second. Here, correct? It's exactly the same scenario as the previous one, except we changed the data size. Just in this question, the same data rate. In your exam question, it will be a different number, but the same approach to calculate. To make sure you're clear, do it for case three. Propagation delay is 1,000 microseconds. What's the total time for the transfer? What's the total time now? Back to case one, where the data size was 1,000 bytes, but the thing we've changed is increased the propagation delay from 10 up to 1,000 microseconds. Still problems with the calculator? Just make sure you have the right prefix. Okay, do it for this one. Tell me the answer for T. T in this case is the total time, like the red line there. The summation of those components. Everything's the same as the first case, except instead of a propagation delay of 10, it's 1,000. 8, 1, 6, 0, plus 1,000, plus 1, plus 1, 60, plus 1,000 to come back. 1 for processing in this example, 160 for the ACK transmission, and another 1,000 for the ACK propagation. Answer, 10,321. Tell me the throughput, calculate the throughput. The same approach as the previous two cases. Anyone get a throughput? This is the same as case one, except the propagation delay has changed. Original data, 1,000 bytes. Time, 10,321 microseconds. And we get 700 something, 775,000 bits per second. And the efficiency, our link rate is 1,000 kilobits. We get 775 kilobits per second, so the efficiency is 77.5%. That's right in full, divided by the data rate, which is 1,000 kilobits per second. What trend can you tell me about stop-and-wait efficiency from this one? Okay, compared to case one, where we got 95.9%, case three, we increased the propagation delay, everything else the same. Increasing the propagation delay reduces the efficiency. Because if you look at the picture, the propagation delay is this time that the source spends waiting. I transmit my data. The propagation delay to get that data there, and to get the ACK back, is the time I spend waiting. Means I'm wasting some time not sending. That means it's less efficient. So the larger the time I spend waiting, the larger the propagation delay, the less efficient stop-and-wait will become. So there are other factors that impact upon the efficiency, the processing delay. But generally the processing delay is quite small compared to the others. That is, processing delay may be several microseconds or milliseconds. In many networks, the propagation delay and the transmission delay is much larger than processing. So sometimes we even ignore the processing delay. We say it's so small it's close to zero. There seem to be a lot of questions, but none of them to me. Just for the next 20 minutes, keep your questions to me. I'm happy to answer. But everyone else wants to hear the answer as well, not just local discussions. Everyone can calculate the efficiency of stop-and-wait. Everyone knows how to maximize the efficiency. Generally you're given a link. That is, you can't change the characteristics of the link. You need to have a link from here to Runxit. It's 15 kilometers long, say a wireless link. You buy a technology that gives you some data rate of one megabit per second. So you can't control the distance and the propagation delay. You can't bring the campuses closer. So the distance is fixed. The propagation delay may be usually fixed. Maybe you buy a technology which gives you a fixed data rate. Then you want to maximize the efficiency if you use stop-and-wait. What do you do? How do you maximize the efficiency given the propagation delay is fixed and the data rate is fixed? You can't control the propagation. You can't control the processing time. You could have a faster computer, but it's usually much smaller compared to the other components. What can you control to maximize the efficiency? What would you do? Data frame. So you change the data frame size to be what? Smaller data frame. A smaller data frame. Look at case one. What was the efficiency with case one? Case one. Yesterday's case one. Data frame a thousand bytes. A large data frame of a thousand bytes. Efficiency of 95%. Case two, which we did today. Small data frame. Efficiency went down. Smaller data frame. Efficiency goes down. Therefore, you want a large data frame. And maybe visually, you can see that the larger the frame, the larger amount of data in that frame, the more time you spend sending, the less time you spend waiting. So to increase the efficiency in this case, if you have a large data frame, not header, but the data inside the frame, make that larger, let's say instead of a thousand bytes, increase it to 2,000 bytes, 10,000 bytes. And then a propagation delay relative to the data transmission is very small and our efficiency is larger. Sending a larger data frame will give us better efficiency when all other factors are fixed. Sending more data at each time. If you've got a very long propagation delay, it can be very inefficient because we send, we wait a long time for the data to get there, then wait for a long time for the act to get back means we spend a lot of time waiting, which is inefficient. Any questions on those calculations? Don't worry too much about this equation. You don't need to remember. It just approximates the efficiency calculations that we just did. But you can calculate it from the diagram. The efficiency is related to the amount of original data in this equation just written as data divided by the time to transmit the original data. I think here data is the transmission time of the original data divided by the time to transmit and complete the frame transfer. So the efficiency is the original data divided by the total time. The total time is made up of the original data, the header, the act, two propagation delays getting there and back. This equation doesn't include processing. In our examples we had one microsecond of processing. Usually processing is quite small, so often we ignore it. And this is just a general equation that ignores processing. So how do you make this value go up? Increase the data transmission time, increase the data at the top or reduce anything at the bottom. Well, if you can't control the propagation delay, the only things you can reduce are the header and the act. That is, if you make the header smaller instead of 20 bytes like in our case made at 10 bytes, our efficiency would go up a little bit, but not much because it's only a small reduction. In practice, the communication technologies we use, the header sizes and the act sizes, are often fixed. They're defined in advance, so you as the user cannot control them. The one thing that you often can control is how much data do you send per frame. So it may be fixed at 20 bytes of header, but you can choose either 1000 bytes of data 100 bytes, 10,000 bytes. So for stop and wait, you choose the largest amount of data per frame to give the best efficiency. So the point of this slide is not to remember this equation, but from the calculations we've just done, make sure you can determine efficiency and compare two different cases. In general, stop and wait flow control is efficient when the data transmission time is much larger compared to propagation time. I showed a picture briefly yesterday. Let me bring it up. I don't think you have it, but this one tries to capture some of those concepts of look at the middle one, which gives us the best efficiency when the data transmission time, this big white rectangle is large compared to the propagation time propagation is quite small compared to transmission. Then we get the best efficiency because we spend most of our time transmitting original data, a very little amount of time waiting for the data and the act to come back. But when the propagation delay is large, we spend much more time waiting means it's much less efficient. Okay, so we know something about stop and wait. What's another mechanism we could use to increase the efficiency? And if you think back to our demonstration with our volunteer yesterday, we had, I was passing messages and one approach was that the receiver would take the letters and save them, store them on the table, put them in some cue or in some memory and process them as we go. In stop and wait, we're doing one frame at a time. What can we do that will improve the efficiency? Maybe look at the right hand case. How could you reduce the amount of waiting time without changing the propagation and the data transmission size? What modification can we make to increase the efficiency here? A simple change to the protocol. What can we do? I don't want to spend time waiting for my act to come back. What could I do? Anyone? Send more data. Okay, or more specifically send us a second data frame. Send one data frame. When I'm waiting for the act to come back for that one, send a second data frame. So in this period, send the second data frame and then when the act comes back, when I'm waiting for the act for the second one, send a third one. So allow the sender to send more than one at a time. That is, with stop and wait, it was send one, wait for the act. A more general approach would be to allow the sender to send several frames before they have to wait for an act. With the aim of reducing the amount of time we spend sending nothing because that's inefficient. And the next, the way to improve stop and wait is to do just that. This issue of what size frames to use will come back to after we go through this next technique. The next technique is called sliding window flow control. With stop and wait, one frame was allowed to be in transit at a time, which means we could only send one before we must wait for the act, which is very bad if we must wait a long time. It gives us a low efficiency. This new one called sliding window, sliding window flow control allows multiple frames, not one, maybe two, three, seven. We'll look at the number in a moment. Allows us to send multiple frames before we have to wait for an act. So the transmitter can send frame one, frame two, frame three, and eventually they must wait for an acknowledgement for frame one, frame two, and frame three to come back. With the aim that while the act is coming back, I'm sending subsequent frames. But before we explain how that works, be aware. The reason why we're controlling how many frames we send is to avoid overflow of the receiver. The issue is that the receiver only has some capability to process the frames that it gets. And we spoke about it has some cue or some memory to store them. So we shouldn't send too many frames such that we overflow the cue at the receiver. With stop and wait, it assumes the receiver can store one frame at a time. We send one, they receive it, store it, process, then they tell us to send the next one. Let's say the receiver could store five frames at a time. Then with sliding window, we could say, let's send one, two, three, four, five, and now stop and wait and for them to send back an acknowledgement saying, ah, you can send more because I'm ready. So sliding window allows us to send multiple frames before we need to stop and pause for some response. We'll go through several sides to explain how it works to keep track of the frames that we send and also that the receiver acknowledges we need some numbers to keep to record which ones have been sent and received. So we need sequence numbers. So in the following, we're going to assume that every frame we send contains some sequence number and we saw that in our example yesterday. Our message had a number in the front and because our frames, we usually include the information in binary and usually we have a fixed size, a fixed amount of space, we have a fixed length sequence number, say a k-bit sequence number. So if k is three, for example, my sequence numbers will range from zero, zero, zero up until one, one, one. There are eight possible values, if we'd have just three bits and the way that our sequence numbers work is once we get to one, one, one, the next number in the sequence we wrap around and come back to zero, zero, zero. So when we have a fixed number of bits, we can't go to infinity. So our sequence number wraps around once we get to the maximum number. We'll see how we deal with that and any issues with that later. So now let's assume every frame contains a sequence number and we'll use those sequence numbers for the source and the destination to keep track of what they've sent already and from the receivers what they've received and acknowledged and we'll go through that now. Take some time to explain how this works. The idea, I'll just illustrate the idea before we explain how it works. With stop and wait we had this, this type of behavior. Just a quick illustration, we send one frame, it propagates, we send an act and it comes back and we spend a lot of time waiting. The idea with sliding window is to allow us to do this. We send one and then we send another frame and maybe another frame with the idea that by the time the act comes back for the first frame, it's not exact but something like this, allows us to send multiple frames before the act for the first one comes back. Again we spend less time waiting for the act which is more efficient. That's the aim here. For this to work, the receiver must have enough space in their memory to be able to receive those frames. That is if B receives those three frames, it must be able to store them in memory. So in fact how many frames we send, if it's three, seven or ten, that will depend upon actually the memory size, the amount of space that receiver has. We'll come back to the, how do we calculate that later? So we want to get something like this which is more efficient than something like this which is stop and wait. So how does it work? Every frame has a sequence number. The rules are that the sender is allowed to send up to W frames, some number of frames W, without receiving an act. So let's say W is three, it means the sender is allowed to send frame one, two, three. Once I've sent the third one they'll have to wait for the act for one of them to come back. Similar to stop and wait but stop and wait, W is one. In stop and wait I'm allowed to send one frame and then I wait for the act. In sliding window we generalize that to say we're allowed to send up to W frames and then we wait for an act. So we've got this parameter W and to keep track of what it has sent and what has been act we can think that the sender records three values. The last frame that we've received an acknowledgement for so over time we receive acts from the destination. We keep track of the last one that has been acknowledged. We keep track of the last frame that we've sent we've transmitted but have not yet received an act for. And we say we can send up to W frames. So let's say W is three, I'm allowed to send three frames, I send one. So now I'm allowed to send two more. The window changes from three down to two if I send one. If I send the second one I'm allowed to send one more. If I send the third one I'm not allowed to send any more until I receive an act. So we'll keep track of how many we're allowed to send in this concept of a window. So we keep track of how many we're allowed to send in this parameter called the current window size. We'll visualize that in this type of diagram in a moment but we'll come back to that after explaining the receiver. It takes a while to get through all of the details of this. The receiver has a similar approach. The receiver expects to receive W frames at maximum at a time. So it has enough memory or buffer space to store W frames. It records when it receives frames. It records the last frame received. When it sends back acts it records the last frame it acknowledged and the window size of the receiver is recorded. As we receive frames we start with a buffer size of W frames, let's say three. As I receive one my window space has gone down to two. I receive a next one it's down to one. I receive a third it's down to zero. If I send an act my window increases meaning I can receive more. The receiver sends an act sometimes it's called a receive ready and I think on the next slide on the diagram from the textbook it's called RR receiver ready but think of it as an act saying I acknowledge what you've sent me I'm now ready for more and the act contains the sequence number of the next data expected. We'll see that in the example. I'm going to try and illustrate these concepts through an example which I'll draw but it will look like this. So I'll draw it slightly different to start but maybe you follow along on here and I'll explain this and what these diagrams on the left and on the right show. Let's say we have A and B and we're going to keep track of those three parameters at each side I don't have much space but the window A is the source so just back to our slides the sender keeps track of the window the last frame act and the last frame transmitted. So I'll record those values as we go the window and transmitted and I'm going to record those values think of those as parameters in the implementation they're going to have some numbers associated with them and at the receiver it keeps track of the frames the last one received the last one act and also the window. The receiver has a buffer which is just memory space to store the frames so also keep track of the buffer and A has data that he wants to send B and I'll just keep track of the data that wants to send. This will make sense as we go through the example. When I say we keep track of the last frame transmitted act received it refers to the sequence number so each frame has a sequence number and we'll modify the values of in this column transmit an act received an act and they'll refer to sequence numbers of frames the window parameter will refer to how many a number of frames a count of frames but let's get started on the example to make more sense of what this shows to get started let's say computer A has three frames of data to send to B so I'll denote that as and we'll start at zero zero one and two so the data that A has to send our frame zero one and two we need some initial parameters for transmitted act and window they're not so important except the window size and we're going to set that for this example to seven it could be a different value but for this example we'll set it to seven and the initial values of these two they'll make sense later we'll also set to seven as we change them we'll see the impact of those values at the start what has B got in its buffer which frames are in the buffer of B none hasn't received anything let's just denote the buffer is empty the window is also seven we have the same parameters on both sides and we initialize these values just to get started to seven seven because that's the window size we set the window size says at maximum A is allowed to send seven frames before it must wait for an act A has three data frames to send we must send them sequentially so it's going to send frame with sequence number zero first is it allowed to send or check the window size the window size says how many you're allowed to send I'm allowed to send seven frames okay so I am allowed to send so A will transmit frame number zero first I'll just draw that here and right inside zero to represent the sequence number of that frame when A transmits that frame let's look at the parameters from A's perspective what data is remaining to be sent one and two so that value will keep track changes to one and two so here what's the last frame transmitted we just transmitted frame with sequence number zero so the last frame transmitted is now zero what is the last frame act it hasn't changed we haven't received an act yet so when we receive an act the last frame act will change but we haven't received it we just sent so the act value stays the same what is the window size the window is how many I'm allowed to send originally seven I just sent one so it's reduced down to six the data frames that we have to transmit the last one transmitted the last one act and though the number of frames are allowed to transmit that's what these numbers represent that's after sending the first frame in your lecture notes we're going to follow this example so I'm writing the actual numbers but in this diagram it draws it as a picture where you think of the frames having sequence number zero one two three up to seven and then wraps around to zero and so on and this picture keeps track of those values initially the window size is seven that's what the blue rectangle illustrates I'm allowed to send frames zero one two three four five and six that is I'm allowed to seven send a total of seven frames although it's not shown the last one transmitted an act is the one previous to zero what's before zero sevens before zero in our sequence numbers so it's not shown on this case but imagine there's a seven here as well I transmit frame with sequence number zero this changes in this example we had three data frames to send let's send all of them I'll do it on my picture and then we'll come back to this one and it'll make a bit more sense am I allowed to send a new frame is a allowed to send another frame why the window is not zero the window says we're allowed to send or how many frames were allowed to send it's not zero therefore yes we are we've got two to send so let's send one send frame number one we'll look at the receiver in a moment so immediately after frame one a frame zero send frame with sequence number one data that we want to send is now there's one remaining two last frame transmitted is one we haven't received an act yet so it's still seven the window goes to five what does a trans what does a do now it sends the that last frame frame two because our window is non-zero we're allowed to send and the data to transmit we only had three to start with so in this example there's nothing to send last transmitted was two last act hasn't changed we haven't received an act yet the window is down to four the window started at seven we sent three frames which is all we have to send so the window is down to four just in this example we started with three if we started with four frames we would allowed allowed to send the fourth one so it depends on what we start with look at these values last transmitted is two last act is seven window is four that's captured in this diagram here the last act this vertical bar the number to the left of that is seven the last transmitted is two the window size is the length of the blue rectangle which is four four frames so maybe when you take your notes you could take it on this diagram because it's the same the same example just represented in a different way any questions before we move on okay so this is just a visualization of what i'm drawing in the on the picture the vertical bar keeps track of the last frame act the left of the the rectangle is the last frame transmitted and the length of the rectangle is the current window size it takes some time for these frames to get to be so now let's see what happens at the receiver frame number zero let's say it's got some propagation delay and doesn't matter the exact value it arrives here so let's look at the parameters at these perspective frame zero arrives last frame received changes from zero sorry changes from seven to zero we've just received frame zero last frame act we haven't yet sent an act it's still seven what's in our buffer we just receive receive frame zero so in our buffer is frame zero what's our window size at the receiver the window keeps track of how many how much space we have in the buffer the original amount of space was for seven frames we just received one put it in the buffer so the amount of spare space in the buffer is now six frames so the window is now six we haven't sent an act yet we'll see that in a moment eventually we receive frame one last frame received goes up to one we haven't sent an act so that hasn't changed in our buffer we now have zero and one so the window size is five from the source's perspective the window is the number of frames I'm allowed to send from the receivers it's the amount of space I have in the buffer and you see that coordinated in that the idea is that the number of frames that a is allowed to send should not be more than the amount of space that b has in its buffer if it's more then we'll overflow the buffer and we'll cause loss of data that's what we want to avoid this is flow control let's consider the reception of frame number two it arrives last frame received is two haven't sent an act yet so that's still at seven windows down to four we've got three frames in the buffer any questions so far that's the easy part what we're doing is try well we're trying to explain sliding window remember the goal was to have some schemes such that we could send multiple frames but remember we don't want to overflow the receiver so we do need some control and the control is done from these these parameters which gives us this concept of this window that says you're allowed to send some frames but up to a limit and the limit would be based upon the window size and eventually the buffer size and once you've reached that limit you'll have to stop and wait for an act to come back we'll see that in a moment be when does be send an act think of stop and wait when did the receiver send an act in stop and wait when did be the receiver send an act in stop and wait what what triggers it to send an acknowledgement back when I received data when do I send an act saying you could send me more when I've finished with that data when I've finished processing the data that was the idea that when I'm ready to receive more and in fact the name if you look at the lecture slides the name is sometimes called receive ready I'm ready to receive more so think in this example B has received three pieces of data it's got them in memory in a buffer it's processing them sometime later maybe it processes those those frames and they remove from the buffer and it can send an act there are different ways to do it let's say we process frame zero we'll remove it from the buffer and then we send an act saying I'm ready to receive one more we could do that and then when we finish frame one send an act saying I'm ready to receive one more and then frame two send an act saying I'm ready to receive one more but let's consider a different scenario let's say I process these three and it's very quick to finish all three so I remove all three from the buffer it depends upon the computer at the receiver how fast and what happens let's say they're all finished all three are processed the buffer becomes empty because we've finished with those three data frames what's the window size it was for we just process three frames it goes up to seven I've got space for another seven and I want to tell a that I've got more space so I'm going to send an act here's my act and here's something new instead of sending one act for each frame received we can be a little bit more efficient and send one act to acknowledge all three acknowledge them all at once and the way that we do that is that the act includes a number saying the next sequence number expected b has received zero one and two I've just finished processing zero one and two what is the next sequence number expected by b three okay so in this act there would be a number sometimes refer to for it to as an acknowledgement number number three it effectively acknowledges these three frames by saying I've just got zero one and two thank you now send me frame number three we're going to send that back in a moment so what do our parameters change to last frame received is still two last frame act what is the value of that parameter after I send this act this act acknowledges frame zero one and two so the last one act is two if we go in order we're effectively acknowledging frame zero frame one and frame two with just one message and the last or that the highest in the sequence there is frame two so the last frame received is frame two the last frame act is also frame two and I've got space for seven more frames that's my window size because my buffer is empty let's just see if that matches the the lecture notes which is this this picture the window size the blue rectangle is seven frames long the last one act is two and the last one received is also two that's what this diagram shows the case before that before we sent the act I don't think we drew it but the last one act that we did the last one act was seven last one received was two and we had a window of four if we send one act to acknowledge all three frames we move to this state any questions on that step that's a little bit different yep why did the act change to two remember the the last frame received keeps track of the sequence number of the last frame we received okay we received zero one and two so the last one received is two last frame act keeps track of the sequence number of the last frame that we received that we've sent an act for we've received zero one and two we process them remove them from the buffer we send an act which acknowledges all three of them the three here indicates the next one I expect is frame with sequence number three so it's effectively acknowledging frame two here last one act is two we're really acting zero one and two but the last one of them is two in that case this number here doesn't mean we're acknowledging three frames it means the next frame expected has sequence number three we don't have to do it this way another way could have been to send an act for frame zero a second act for frame one and a third act for frame two we could have done that and we'd get the same result eventually here but it's just a little bit of a waste send three frames when we can do it with just one so we can be more efficient by by sending just one frame in this case if you checked send frame for send an act for frame zero and then an act for frame one and an act for frame two you'd end up with the same values eventually here it'd give the same result questions before we keep going any questions any problems so that was a new concept don't send an act necessary for every frame you get be a little bit smarter and send one to acknowledge multiple frames at once save sending messages what happens next just remind myself eventually the act gets back what happens from the perspective of a still got no data to send last frame transmitted is still two I haven't sent any more since then last frame act is I just received the act the act contains the number saying b expects frame number three which implies it acknowledges up until frame number two if b expects three and everything goes in order it means b must have received up until two so the last frame act becomes two what's the window how many am I allowed to send I've got none outstanding I haven't everything's been act I haven't sent any that I'm waiting for an act for so I'm allowed to send seven more and you see the coordination it's not at the exact time but the the exchange of the packets keep the source is allowed to send seven more which makes sense because b expects or has enough buffer space to receive seven more if we had seven here and six here we'd have an error something's gone wrong this protocol avoids that case where we're allowed to send more than what the buffer can handle the user the human sitting at computer aid creates the more data just for this example four more data frames three four five six so we create some data to send before we had nothing to send and do we send any data oh yes we can our window is seven we're allowed to send so let's send frame with sequence number three and last frame transmitted will become three act hasn't changed window goes down to six we're allowed to send and we've got four five and six outstanding sorry let me just remind myself from the example we're going to send all four that's at this point here we'd receive the act we've got four more data frames to send let's send them frame three four five and six and eventually at the end there'll be no more data to send what are the values of last frame transmitted we just sent six so last frame transmitted is six last frame act we haven't yet received an act so it stays at two window size we had a window of seven we sent four we've got three more allowed i'm going to need some more space probably going to need more time as well and maybe we'll go back and see what happens this this is just one example it depends upon the amount of data we have and so on but just trying to illustrate how we keep track of those values so we've got to the point we send four last frame act is two last frame transmitted is six window size is three frames that's what this illustrates i will not try and draw it with the last couple of minutes but the you will finish the picture in this example just to illustrate something different b receives frame three frame with sequence number three and in this case it chooses to act immediately in the previous case b receive zero one and two and then send an act for all of them but in this second case it receives just one frame and then sends an act why would it do that why do it differently it really depends on the timing that is it's best to send one from one act for multiple frames receive because we don't waste the transmission of extra acts but sometimes the receiver may decide that okay we need to send an act now otherwise a will have to wait a long time for an act to come back there's no way for you to know in advance which one it would do whether it sends one act for three frames one act for two frames one act for every frame and it may change in practice but just illustrated that it may change so in this case an act is sent three more received from the receiver's perspective last frame act is three we'd receive three send an act for three we've received four five and six last frame received is six we expect in the future another four when a eventually receives this act last frame act is frame three last frame transmitted is frame six we're allowed to send another four more try and finish it's there on the slide but try and finish this diagram to make sure you know what happened given so so you know those numbers and then check it against what you get here it's the same values just represented in a different manner this shows one example of sliding window flow control what we'll do next week is look at in ideal case how efficient will it be compared to stop and wait okay that's one thing we want to compare what's the efficiency we can achieve using sliding window versus stop and wait