 Recall the flow control, the purpose of these protocols is to make sure that we don't send too fast for the receiver. Both stop and wait and sliding window, they both have the same aim. Sender has to send data, but the receiver in some cases may be too slow to process that data. So these protocols, so the rules that they follow, which is called a protocol, defines or controls how fast the sender can send. With stop and wait, the sender can send one frame before it must stop and wait for an act to come back. And the act only comes back when the receiver is ready to receive more. So that's how the receiver controls how fast the sender sends by sending back acknowledgments. But in some cases stop and wait is very inefficient because we send data, then we wait a long time for the act to come back, maybe there's a long propagation delay, and all that time spent waiting is time spent not using our link, not sending data across our link. So stop and wait can be inefficient, especially when the propagation delay is long. Sliding window tries to improve upon that by still having flow control. So it still means that the receiver will send back acts when it's ready to receive more. So there's still control of the sending rate by the receiver, but in this case the source is allowed to send, we call a window size of frames, more than one frame at a time. Then multiple frames before it has to wait for an act. The difference in terms of flow control with sliding window, the receiver must be able to store in its buffer multiple frames. With stop and wait, the receiver needs a buffer for one frame. It receives a frame, puts it into memory, into a buffer, and then processes. When it's finished it sends back an act, that's in stop and wait. With sliding window, the source sends multiple frames, they'll be received, put in memory at the receiver, maybe 10 frames, and they are processed one at a time, and then acts may come back. So with sliding window, the idea is to be more efficient than stop and wait, but the trade-off is that you need more memory space at the receiver. So sliding window requires the receiver to have more memory to store more frames at a time. The other problem with sliding window, and you've noticed, is it's complex, that is the protocol, the rules that you need to follow, is much more complex to understand and also to implement compared to stop and wait. So let's recap on what we know about sliding window and then we'll analyze the performance and see how it does compare with stop and wait in efficiency. We have sequence numbers to keep track of frames. Every frame has a number. We wrap around when we get to the maximum number, because we have a limited number of bits. So we come back to zero. That's one concept. And both the sender and the receiver keep track of what they've sent, what they've received, and what's been act. For example, the sender keeps track of the frames which it has received an acknowledgement for. I've sent some data frames. I've received acts back. Think of those frames, those data frames as done, are finished. If I send data frame one and I get an act back, then I don't have to worry about that data frame one again. That's been processed. So that's the last frame act. Last frame transmitted from the sender's perspective, I've sent some frames to the receiver, but I haven't yet received an act back. Sometimes I'll say they're outstanding. We're still waiting. So at some point in time, some pieces of data are finished. Some have been sent, but not yet act. And other pieces of data we can potentially send in the future. And the window size indicates at this point in time, how many more data frames am I allowed to send? So on the slide, we visualize that as to the left of this vertical bar are frames which are finished, done, they've been acknowledged. To the right of the vertical bar and before the window are frames which have been sent, but not yet act. I've sent frame six, I've sent frame seven, but I'm waiting for the act to come back. And in the blue rectangle here, this is the window. This says, I haven't sent these frames yet, but I'm allowed to send another five. There's a right five in this case. Frames beyond that, I'm not allowed to send at this point in time. All these frames out here, that's what it tries to visualize. And these parameters in an implementation, they change over time. When I receive an act, say I receive an act for frame six, then you can think this vertical bar moves in that six becomes a frame that has been acknowledged. It's no longer outstanding. We're no longer waiting for the act for six. So you can think this bar moves to here when I receive an act. And also, when I receive an act, I'm allowed to send one more frame. So the blue box extends to the right because the total number of frames which I'm allowed to send, that is those that have been sent and not yet act, plus those that I'm allowed to send. So between the vertical bar and the end of the blue box, this is always in this example seven, two plus five, seven. And over time, as this bar moves and this blue box extends, then it's always seven. That's our maximum window size. And that's a parameter of the protocol. In this example, it's seven. As I transmit frames, if I transmit frame number zero, you can think, okay, zero becomes into this set of frames transmitted, six, seven, and zero. And the blue box gets smaller on the left-hand side. I'm allowed to send another four so that this space is always seven frames. And the blue rectangle is our window, and that's where the name comes from. As we transmit frames, the window closes on the left. As we receive acts, the window opens on the right. And over time, you can imagine that window slides along. It's similar with the receiver, except the receiver, of course, keeps track of what it has received, six and seven, for example, it has received. What it has buffer space available to receive in the future, we have a maximum buffer size of seven frames. I've received and stored two frames in the buffer. I can store another five, and those frames which the receiver has received end act. Similar concepts between send and receiver. Any questions on sliding window before we calculate the performance? It's hard to remember all those steps, but try, for example, I think one quiz question asks about these numbers. So try and understand how those numbers are updated as packets are transmitted and acts are received. We went through an example last week based on this one. What we want to do now is say, okay, let's consider the best case scenario when we use sliding window and compare the performance of using sliding window to, say, stop and wait and see how they compare. In this example, I come up with the example we use as a case where we send three frames and then a little bit later we send four frames. Let's consider a different example and let's assume the sender has an unlimited supply of frames to send. The sender has an infinite number of frames to send. There's no need to wait for more frames. It always has something to send. And for simplicity, let's assume the destination, whenever it receives a frame, a data frame, it sends back an act immediately. The processing is so fast that I receive a data frame, process it in zero time and send back an act. That's the best case in terms of performance. Always sending data according to the rules and process as fast as possible. We'll do that in a moment. This example was different where we sometimes have data to send, like three frames, but then we had nothing to send for some time. This example also considered the case where we sent one act, this receive ready, one act to acknowledge three frames. That's also possible. But we're going to consider the simpler case, one act for every data frame received. We want to consider that case and calculate the efficiency. If you flick forward a few slides, you'll see the example that I have rather than try and draw it again. This one. We'll scroll down in a moment, but make sure you have this one. So I think at the end of your handouts, there's two pictures. Go to the end of your handouts. And this is the first picture. There's one on the back page which is slightly different. We'll go through both. It doesn't come out perfectly in black and white, but I think you'll see the patterns in a moment. The green color may not come out when printed. Let's explain the scenario, and then we'll go through the timing diagram and see what happens and then calculate the efficiency. I've set up some numbers just to make it a little bit easier to add them up rather than using, rather than calculating all these values in advance, I said, the propagation delay is 200 time units, 200 milliseconds, 200 seconds. I don't care in this example what the actual units are, but 200 time units is the propagation delay. So to get a message from A to B takes 200 units. Maybe an example will say milliseconds. The data transmission time, which is the time it to transmit the entire data frame is 100 time units in this example. And I'll say that that data frame is made up as original data plus header. And in this case, the header is 10% of the entire frame size. So if it takes 100 time units to transmit the entire frame, if the header is 10% of that, then we can think it takes 10 time units to transmit the header and 90 to transmit the data. We'll use that later, though, that split of header and data. The act transmission is just 10 time units. And in this first example, we'll use a two-bit sequence number. So the sequence numbers go from zero in decimal, zero through to three, and then wrap back around to zero through to three and so on. And that's what we'll draw here. The maximum window size is three. W is three in this. And in this diagram, as we draw what happens at the source A and the destination B, we'll keep track of the window at A. It'll be similar at B. But just for simplicity, we'll just look at A. And we'll look at if A's always got data to send, what efficiency can we achieve in this scenario? So and I've put the numbers on here. So the first thing, if we look at A, I've numbered, okay, so the data frames it has to send. It keeps going, but we start at zero, one, two, three, wrap around to zero and so on. Initially, with a window size of three, if we've sent nothing, we're allowed to send three frames. And we send them in order. So I've highlighted in green those frames which were allowed to transmit, zero, one and two. So at the start, A is allowed to send zero, one and two. We cannot send three just yet, because the window is just three frames. It's allowed to send zero, one and two, so let's do that and send them in order, of course. We transmit frame zero, starting at time zero. Transmission time is 100 time units, so we'd finish at time 100. After transmitting frame zero, we'd mark frame zero as one that's been transmitted, but not yet act, and that's what I've marked in red here. One and two are allowed to be transmitted. Zero has been sent, but we haven't yet got an act back for zero. So I'm just visualizing similar to what we've done in the previous examples. Any questions so far? Sliding window. Now's the time before we get into the harder parts. This is here, but not so good. This picture is in the last slide of your handouts, the second to last page. Go right to the end. There are two, one with two bits and one with three bit sequence number. We'll do two bits first. So we transmit frame zero. It's going to propagate across the B eventually, we'll see a little bit later. But after transmitting frame zero, since we're allowed to send two more, let's transmit frame one. And after transmitting frame one, we're allowed to send one more. So we transmit frame two. And after transmitting frame two, from A's perspective, there are three frames which we've sent, but not yet act. Our window is, what's our window size here? Zero. The window starts as three frames, two, one, zero. So the window is closed, meaning we're not allowed to send any more. After sending two, frame two. Three frames have been sent, no act yet. And that will finish at time 300, three by 100, which is our data transmission time. Frame zero slowly propagates across the B. If it finished transmitting at time 100 and the propagation delay is 200, then frame zero arrives at B at time 300. So that's when it arrives. And in this case, B immediately processes. So we're not showing any processing delay. It's immediate, receives the data done, send back an act. So this small rectangle represents the acknowledgement saying, thank you, please send me more. And the act takes 10 time units to transmit. So this act of frame zero, as that propagates back, it's going to arrive at time 510. Just for that first frame, just confirm that calculation of 100 for data transmission, plus 200 propagation, plus 10 for act transmission, plus 200 propagation back, 510 in total for that one frame transfer. Any questions? In fact, that's for frame zero, that's the same as how we'd calculate for stop and wait. Data transmission, propagation, act transmission, propagation. We've set the processing to zero. In the meantime, what's also happening is that frame one is propagating across. It finished transmission at time 200. It would arrive at time 400 and be processed and an act for that frame would come back. In this example, we send an act for every data frame we get. And the frame two will arrive here at, what, I think, time 500 plus 10 to transmit the act back. And eventually we'll see later the act will come back. So let's look at A again as the act comes back. What's happened? We transmit three frames and now we're waiting for the act to come back. The act arrives back at time 510. Actually, we'll stay up so we can see the whole scenario. So at time 510, the act comes back. Before, from A's perspective, there were three frames outstanding, transmitted, not yet act. When we receive the act, what will the act number be in this frame? It's not shown here. The act number. This one comes back. Inside an acknowledgment, we include a number in a similar way. In a data frame, we include the sequence number. The number we include inside the acknowledgment, I call the act number, the acknowledgment number. What's the value? I hear zero, two, they're both wrong. Wrong. One. Why'd we skip? We remember the act number indicates the next frame expected. So I receive from B's perspective, it receives frame zero. Thank you for frame zero. I now expect frame one. That's what the act number indicates. So the act number of the first act will be one. Of course, B sometime later receives frame one and sends an act. That act will have an act number of two, saying I've received one, now send me two. And when we receive frame two, we'll send back an act number saying please send me three, frame number three. It's the next number expected. Coming back, frame zero sent, act with act number one comes back. Question, the act number indicates the next number that the receiver expects to receive. So at time 300, B has only received one frame. That frame has sequence number zero, so the next one in order is one. Therefore I send back act with act number one. Of course, a little bit later I receive frame number one, therefore the next act will be two and so on. So at time 510, frame zero has been acknowledged. How do we know that? A has sent zero, one and two. The act number comes back one, which means to A, okay, I've sent zero, one and two. If B is expecting frame number one, that means B must receive frame number zero. So upon reception of this act, A knows frame zero has been successful. So I've marked this in this grey box. Zero becomes one that's been act already. Zero's done. It's been successfully transferred. One and two are still outstanding. Our window, because zero's done, allows us to send one more frame. Remember the total number of frames that can be outstanding plus we're allowed to send is three in this case. That is the red plus green is always three frames. You see that here? So therefore we receive an act for frame zero. Two are outstanding. We're allowed to send frame three. So let's do that immediately. Transmit frame three. And at that point, one, two and three become outstanding. Because we've sent one, two and three. It takes one hundred to transmit. And then, you can't quite see here, but at time 610, the second act comes back. Transmitted at time, or finished transmitting at time 410. 200 to propagate at time 610, the second act comes back. Acknowledging the second frame. Frame with sequence number one. So we'll see that, okay, frame one's done. This second act acknowledges frame with sequence number one. Frame one is finished. I've got two outstanding, frames two and three. Let's send another one. We're allowed to send frame zero now. And in this example, that act comes back at 610. And in fact, we finished transmitting frame three at exactly 610. So instantaneously, we can start transmitting the next frame, which is zero. We've wrapped around. Send frame zero. Okay, two, three and zero are outstanding. We're not allowed to send any more yet. But the third act comes back at time 710. Meaning zero, one and two are finished. Three and zero are outstanding. We're allowed to send one more. So let's transmit frame number one. We transmit that. And now we have three, zero and one outstanding. Our window is closed again. We're not allowed to send any more. And you can follow the timing. Okay, if we transmit frame three, finish at 610. The data arrives at 810 plus 200, plus 10 for the act, plus another 200 to come back. And that acknowledgement for frame with sequence number three will get back at time 1020. Receiving an act allows us to send one more. We send frame two. When we finish that, we'd receive the second act. You can see the dashed line here, allowing us to send another one, and so on. And that's about as far as I draw. It would keep going, two, three, zero. And then stop for a while. And then one, two, three. And then stop, and so on. You see in general what's happening is with a window of three in this scenario, A can send three frames, and then it must wait for the act for the first one. Send zero, one and two. And then when the act for the first one comes back, I can send more. And the timing works out that when this one is finished, I get the act for the second frame. Then the third, allowing A to send a batch of three again, three more frames, and then wait for the first act of those three frames to come back, and then send another three frames. And it will keep going like that as long as we have data frames to send. Any questions about why that happens? Some of those numbers, how they were calculated. It's in fact, sometimes people find this easier to understand than what we covered in the previous lecture of what happens when we have pauses and processing time. This is considering the best case. No processing or zero processing. Always send an act back. Always have data to send. And we see the general pattern is that, okay, from zero to 510, we got to send three frames. And then from 510 through to 1020, we get to send another three frames. And if you keep going, you'll see every 510 time units, we send three frames. And from that, you can calculate your efficiency and or throughput. Three data frames per 510 time units. How much data? This is a slightly different step. Here we don't know how many bits. I just gave you the transmission time. So we can't calculate throughput, but we can calculate efficiency. And you see it at the bottom of the picture. A sends... So in this case, A sends three frames of data to B, then waits for the act for the first frame. So that's the pattern. And then it sends another three. So over a long period of time, A is delivering three frames of data to B every 510 time units. If you keep drawing that picture, that's what you'll see. 510, 1020, and then another 510 and so on. In our setup, we said, or I said, each data frame consisted of 90% of real data and 10% of header. Just in this example. So the question is, what percentage of the time do we spend sending real data? And it's calculated there as efficiency, but sometimes you can think about it as, okay, in that period of... from zero to 510. That's the total time. What fraction of time did I spend sending real data? Well, I spent 300 time units sending data, but only 90% of that was real data. 10% was overhead. So what's 90% of 300? 270. So in that period from zero to 510, 300 time units spent sending frames, 270 time units spent sending the real data. So we can say, every 510 time units, I spend 270 time units sending real data. And you can look at it the same from B, every 510 time units, it spends 270 time units receiving real data. Because in this case, everything that is transmitted is received. There's no loss. And that gives us our efficiency, 52.94%, which is just 270 divided by 510, but expressed as a percentage. This is slightly different from what we've seen in the previous example. Here we don't know about throughput because we don't know about the actual data size. We just know about a ratio of the timing. Questions? Before we move on. Should be able to calculate such efficiency given a particular scenario. How do we get higher efficiency? More window. Good. I should have said how do we get higher efficiency given the same conditions here? That is, we can't change the propagation delay. Let's say we can't change the data size. Well, to get higher efficiency, spend more time transmitting. And you see the problem in this case is that transmit for 300 time units, then wait for 210. Transmit for 300, wait for 210. That time spent waiting is wasteful, and that leads to a lower efficiency because we're not sending anything. So how do we get to send more if our window was larger? We could send not three frames, maybe four or five or six, a larger window. And the next example that you have in front of you shows that. Same setup, all the same conditions except it's now a three bit sequence number, zero through to seven, and we set the maximum window size to seven. You may see some pattern between the sequence number and the window size. And when we come to back to the slides and back to error control, we'll see some more formal relationship but generally it's the case that the window is based upon the sequence or the length of the sequence number, the maximum window. If we had a window of eight, that is a three bit sequence number and a window of eight, it wouldn't work. There would be problems and we'll see those problems later in error control. If we have a three bit sequence number and a window of six, it works okay. But typically we set the window size to be one less than, well, one less than the number of sequence number. So in this case we have eight possible values. We set the window size to seven. Everything else is the same. You see here A can send seven frames at the start, zero through to six, follow through what happens. I recall there's a mistake somewhere because these blue numbers, we'll see who identifies it somewhere. Unless I fixed it last year. Transmit zero, one, two, three, four, five, six because we're allowed to send six, sorry, seven frames, zero through to six. And you see that from A's perspective the summation of the red blocks plus the green blocks is always seven. Five have been sent here, zero through to four, two are allowed to be sent at this point in time. When does the first act come back? Same time as in the previous example. Frame zero finishes transmitting at 100 plus 200 to propagate, 10 for the act, plus 200 to propagate back. At this time, 510, the first act comes back. So let's look what happens there. Let's say we had just started transmitting frame five. This is at time 500. So zero, one, two, three, four, and five have been transmitted. Six is allowed. But then we receive the act at time 510. Frame zero is done. That's finished. When we receive an act, we're allowed to send one more. So zero is done. We're now allowed to send both six and seven. So that's at this point in time. Think at time 500, we transmit or start transmitting frame five. So five is in the red box here. But then a little bit later, at time 510, we receive an act, meaning frame zero is done, the first frame, allowing us to send one more. So we're allowed to send six and seven. We transmit six, and at time what, 610, the second act would come back. 300, 400, 410 plus 200 at 610, the second act comes back. And you see at time 600, zero, one, two, three, four, and five, and six have been transmitted. Allowed to send seven. A little bit later, we receive the act and allowed to send one more. And it keeps going like that. Transmit one, but then a little bit later, receive the act for one of the earlier ones, allowing us to send one more. The window never closes. You see the green blocks, it never gets down to zero. The result, A is always transmitting data frames, never waiting for an act. And that's a good thing. That's the best efficiency we can achieve. Where's the error in that picture? At 700, good. This should be 800 here. The time in which we finish transmitting frame number seven, it's the eighth frame. It takes 800 time units to transmit, so this is a mistake. This 700 should be 800. Change it on your slide, on your picture. It's at the same location, but just change 700 to 800. So just by changing the window size, making it larger, we've improved our efficiency in that we're always sending. No time waiting. What's the efficiency? Well, again, what fraction of time do we spend sending real data? We're always transmitting data frames. 90% of the time is spent sending real data, 10% spent sending overhead. We get 90% efficiency in this case. That's just due to the split between the real data and the header. The only overhead is the header. There's no waiting. Questions on sliding window. How to calculate efficiency under different conditions. This one confuses people a little bit, the efficiency here. We don't look at some total time. You could, but you see that we're always sending. Every 100 time units that we transmit, 90% of that time is sending real data. We do that continuously, meaning we're 90% efficient. The only way to improve is to do what? How do I make this efficiency go higher? Anyone? I want more than 90%. I'm not satisfied. What if we increase the window size? What happens? There's no data rate in this case. I haven't specified the data rate, but we could change it. A larger window will not help in this case. If instead of 7, we could send 15 or a thousand frames, we cannot do any better because how do we do better than always sending? Even if we have a window size of 15, we've always got something to send. We never spend any time waiting, which gives us the same scenario. We always have to wait for the previous frame to be transmitted. A larger window doesn't help in this case. So if we don't increase the window, how can we increase the efficiency? What can we change? Propagation delay won't change anything, unless if I increase the propagation delay, the worst I can do is make the efficiency go down. It won't go up. Data size on the right track compared to what? Why is it 90% efficient? Well, if we're always transmitting of the 100 time units transmitting I said at the start, 90% was data, 10% header. The only way to increase the efficiency in this case is to make the header smaller relative to the data. Maybe it was 95.5, then it would be 95% efficient. 99.1, 99% efficient. So yes, increase the data relative to the header. That's the only way. Now in practice, we usually have a fixed size header. We cannot change that. The only thing we can do is make the data larger, the real data. So in this case, it depends upon the ratio between data and header. Any questions on sliding window? Almost finished it. What about, so in this scenario, we got a efficiency of 90% when we had a window of 7. With a window of 3 frames, we got an efficiency of about 53%. What about a window of one frame? W equals 1. Efficiency go up or down? If the window is 1, the efficiency goes down. When the window is 1, what do we get? Look at this picture. Here the window is 3. With a window of 1, we'd send frame 1 and then wait for the actor to come back. Then send the next and wait for the actor to come back. When the window is 1, we get stop and wait. Stop and wait is just a special case of sliding window when the window size is 1. Window size of 1 means you're allowed to send one frame before you have to wait for an act. And that will give us a lower efficiency. You could calculate 90 time units transmitting divided by 510. 15% or something. So under a, usually with a specific link, when we know the propagation delay, we know the data rate. For a given data size and header size, we can find the optimal window size. The optimal window size will be large enough such that we're always transmitting frames. In this case, 3 is not optimal. It's suboptimal because we spend some time waiting. What do you think the optimal window size in this case is? In our scenario. Do you think 4 would be okay? 4 would not be okay because the fourth frame would finish at time 400 and then we'd have to wait till time 510 before the act comes back. So we'd spend 110 time units waiting. So 4 would not be good. It'd be better than 3 but not as good as 7. 5 would finish transmitting the fifth frame at 510 and wait just for 10 time units before the act comes back. Almost optimal. But still a little bit of time waiting with 5 frames. So 6 would be optimal window size in this case because 6 will allow us to transmit frames and the first act comes back when we're transmitting that window of frames. If you drew it with 6 it would be 3, 4, 5 while we're transmitting that sixth frame the first act comes back allowing us to keep going continuously. In practice we often set the window size the maximum window size to be based upon the sequence number. Why not just set the window size to be 1000 to be very big? What's the problem? Why not set the window size to 1000? We see with 7 it gives us the best efficiency with 1000 we'd get the same efficiency but what's the problem with the large window? Sorry? Check? Check what? This protocol would be the same if we have a large window. If the window is 1000 what would the problem be? It's not shown here but remember we're doing flow control the window indicates how many frames the receiver must be able to buffer so a window of 1000 means the receiver must have memory to store 1000 frames a window of 7 it means it just needs memory to store 7 frames so it uses less memory at the receiver with a smaller window we'd like to really in practice it depends on how much memory the receiver has but having a window of 1000 doesn't increase the efficiency and increases the memory requirements of the receiver so that's the problem the window indicates how much memory is needed at the receiver the more memory needed the worst that case is you go calculate this example tonight this example is the same as the one you have in front of you the answer for this is the exact numbers in the pictures that we just went through on those two slides 90% payload what does payload mean? payload means the original data 90% real data 10% header and you do the calculations you get the exact numbers as the pictures that we drew so in fact you've got the answer to that example already ask now if the window size decreases the efficiency decreases if the window size increases what happens? what happens? there's some upper limit in this case if the window size was 1 it would be very low efficiency we didn't calculate it but a low window size of 1 the efficiency would be quite low it's just stop and wait a window size of 3 we calculated to be 53% a window size of 7 we got up to 90% so yes increasing the window size increases the efficiency but up to some point we got to a window size of 7 the efficiency would still be 90% so the efficiency at some point we reach the maximum so it goes up and then it hits the peak so under certain conditions there's an optimal window size one that is large enough such that we get the highest efficiency the peak efficiency so if the window size increases up to that maximum the problem of going further for the window size 15, 30, a thousand efficiency stays the same but the memory requirements increase so that's the problem of keep increasing the window size we need more memory at the receiver yes if the window is 5 in this case you would give the sub-optimal correct? it's not quite 88% is being calculated if the window is 5 if the window is 5 we could transmit 0, 1, 2, 3, 4 that is 5 frames we'd finish transmitting the 5th one at time 500 5 times 100 finish at time 500 spend 10 time units waiting small amount to wait not quite the best we can achieve so 6 is the best case any questions at the back I'm just in this case this line indicates when we receive the ACK in its entirety at time 510 I've just got it now I'm allowed to send frame 3 so this rectangle shows us the time it takes to transmit 3 I start transmitting at time 3 sorry, at time 510 the frames coming out of my computer it takes 100 time units to transmit so I start transmitting at time 510 I finish transmitting at time 610 that's what it visualizes there so it frame 3 in full arrives at time 810 the last part any other questions on sliding window efficiency remember stop and wait is just sliding window when the window is 1 so in fact if you know sliding window you can forget about stop and wait just remember the window size of 1 any numbers that you can tell us about the efficiency what's the answer 500 times 90 divided by 510 right, so in this case efficiency is the fraction of time spent sending real data divided by total time 88% someone calculated for the frames so we know sliding window we know how to determine the efficiency and we also know the operation of how we keep track of the frame sent, received and act before we move on to the next topic any last questions on sliding window you'll calculate efficiency in the quiz you can try will you get it correct are there any problems easy good no, not okay what's not okay ask me and then others we'll hear your question and get the understanding 510, everyone can calculate where 510 comes from 510 510 is just the summation of focus just on the first frame 100 to transmit get your calculator 100 to transmit plus 200 to propagate so we've got 300 10 to transmit the act, 310 200 to propagate back the first act arrives in it's full in it's entirety at time 510 and the reception of the first act is the time when A can send more the only thing that allows A is receiving an act so that's why we care about this time because at that point we can send more and we can see if you follow it through we'll see the pattern every 510 we send a bunch of frames that bunch is based upon the window size I'm not sure if that answered the question anything else in the second example it's a bit harder to see the timing I didn't draw them all in this case for example this is 800 not 700 that was an error I think if you calculate those times yourself you see that we finish transmitting each frame at the 100 interval at 700, 800, 900 and the act arrives 10 units later because there's a 10 for transmission of the act so you can work out the exact times there but it's always the case in this one in that the act the first act arrives while we're still transmitting that first window of frames the window is 7 it takes 700 transmit the first act arrives before 700 allowing us to just keep transmitting because the act arriving means we're allowed to send one more and you see the green boxes are always greater than one or two in this case it's never closed but the exact timing maybe go through and determine those times of course if we have a different propagation delay different numbers the window size we'd have to find the optimum one based upon those conditions back to our slides let's keep going few other things that we maybe haven't mentioned some we may have not so important at this stage in some cases you can have a receive not ready frame receive ready I've called an act a receive not ready frame is an act that says thanks for the data you've sent me but you're not allowed to send anymore send anymore yet an act says thanks for the data you sent me you can send me more a receive not ready is a special case you can indicate yes I've received your data but you're not I'm not ready to receive more yet this becomes useful when we in practice when you look at real protocols we can reduce them overhead by using these type of frames but I think we will not see any examples of that piggybacking everything up until now we've looked at one direction A sending data to B but of course in real life A may want to send data to B and B wants to send data back to A then in that case we just do the sliding window independent in both directions so if A sending data to B it maintains its own parameters for its window for the data coming from B to A it's completely separate there's no connection between the different directions but in practice if B is sending data to A instead of sending an AC from B to A and then sending data from B to A piggybacking is the concept of you've got two different frames going in the same direction join them together send one frame and include the information of both of them in one frame it cuts down on transmissions I think we will not cover that yet we may see it maybe towards the end of the course we will see some specific examples of protocols that use sliding window but if you ever come across piggybacking it means having combining a data and the AC into a single frame I think that's all to say about sliding window which leaves us with error control up until now everything's been perfect we send data it gets to the destination the next issue we send data and something goes wrong how do we deal with that and that's what error control is about let's get started on it turns out error control protocols will go through three basic mechanisms the first one is based upon stop and wait it's just an extension of stop and wait second to are extensions of sliding window so once you know stop and wait and sliding window, error control is much easier we'll just start on stop and wait error control we've got two things that may go wrong in terms of sending frames I send a frame from A to B but it doesn't get to B A transmits it something goes wrong with the link or the connection such that the frame never gets to B we call that a lost frame frame was sent but not received the other thing that can go wrong is I send a frame from A to B B receives it but there are some errors inside that frame the data is wrong maybe we'll use error detection to detect that we call that a damaged frame in the error control mechanisms we usually treat them the same if I receive a frame that's damaged I just discard it, throw it away as if I'd never received it that's the common approach that a damaged frame one that's received but has errors is usually just ignored by the receiver how do we deal with errors we'll go through mechanisms retransmit so we'll see these through examples and we'll go through three techniques of retransmissions automatic repeat request ARQ protocols stop and wait, ARQ go back and select and reject ARQ let's today just start on stop and wait it's based on stop and wait flow control source transmits a single data frame after transmitting it starts a timer so we have a stop watch we start it after transmitting that frame and we store a copy of that frame that we just sent if we receive the ARQ before the timer expires then that ARQ indicates the frame was successfully delivered and we move on to the next frame if no ARQ is received before the timer expires then we'll retransmit so the timer tells us when to try again, render, retransmit there are a few other cases but it's straight to two or three examples here's stop and wait ARQ unless there are any questions let's concentrate on this one so that you can do this just as easy as you can do flow control any last questions on sliding window? stop and wait ARQ it looks the same as stop and wait flow control send data data arrives at B B when it's ready for more sends back an ARQ A sends data arrives at B maybe B processes it for some time sends back an ARQ data, ARQ, data, ARQ nothing new there this is the case where there's no errors the normal case I've attached some numbers in here some sequence numbers we'll explain why they are needed later what happens if same scenario but this data frame, the second data frame doesn't get to B A transmits data one there's an error in the link such that B doesn't receive it draw what happens that is one lost data frames try and work out what will happen if we use stop and wait ARQ try and draw what happens if the second frame there's data with one in the brackets here it doesn't get to B so the first frame is normal and the second one is lost so the first data frame is successful the ARQ comes back this is our data this is our ARQ then we transmit the second data frame we say that data frame is lost that is something goes wrong in our link such that B doesn't receive it what happens next that's what we care about what's going to happen time when the timer expires where you're correct at A so what I haven't drawn here is that after A transmits the data it starts its timer think it's got a clock and the idea is that let's say we started at zero and it goes up it reaches some predefined value we say that timer expires sometimes we say it times out that predefined value would be set we don't know the value at this stage but once it reaches some maximum value the timer expires we get a time out that triggers a retransmission in this case B is not going to receive the data so B is of course never going to send an ARQ back we're never going to get an ARQ so what A does is starts its timer we can think that A starts the timer here and that timer is some value such that so we start here and at this time the timer expires that is we reach some predefined maximum and when the timer expires or sometimes say a time out occurs that triggers A to think something's gone wrong ah I've sent data I'm waiting for the ARQ I'm waiting, I'm waiting I've waited too long let's assume that the data didn't get there and let's try again so we retransmit and in these boxes I don't know if I did it on the slide in the slide I said data one data two, data three the first one of course was data one the next one was data two what's this box this is a retransmission of the data the second piece of data it's another frame of course but the data inside it is the same as the previous frame it's a retransmission why did we retransmit because we waited long enough for the ARQ but an ARQ didn't arrive let's say in this case the error doesn't occur so it arrives at B everything goes fine the ARQ comes back and from B's perspective at this time data one was received and processed and from B's perspective at this time data two is received and processed and of course let's say everything continues normally for any subsequent data so this is the case when there's just one error such that one frame doesn't get to the destination we time out and retransmit that previous frame any problems with stop and wait ARQ we've still got five minutes left on our timer so we can go through the next example next case consider that the data does arrive but the ARQ gets lost try that so we've just done lost data now consider a case with a lost ARQ data gets there but the ARQ doesn't come back let's say the first frame is successful the second frame is sent but the ARQ for the second frame doesn't get back same as before second frame OK arrives at B ARQ comes back arrives at A A transmits the next data frame arrives at B B sends the data back sorry B sends an ARQ back there's an error what happens next and I'll just note A sent data to B B received the first piece of data OK data one successful sends back the ARQ B receives the second piece of data data two successful but sends back the ARQ what happens next what does A do what happens at A does A receive the ARQ no so what A does it sits there forever waiting it will time out it will wait for a certain period of time and then say give up I waited too long for the ARQ I never received it same as before retransmit so we'll have a time out after some time I'll just write this time it's a time out and that triggers retransmission and let's say that arrives this time and let's go back I forgot our numbers this was the first piece of data this was the second what is this piece of data it's a retransmission of the second piece of data what happens at B what does B do in this case B receives the data I just received the data frame what do we do at B you're the receiver let's say what was the contents of the data let's say data frame 2 was sending money from some computer or from an ATM to the bank or some money exchange and the message was send Steve 10,000 baht that was message number 2 and computer B is the bank that processes it and transfers 10,000 baht into my account what happens at B in this point I receive another 10,000 baht that is data 2 the same data is received at B what does B do if B accepts and uses that data we have an error because the same data arrives at B and B receives it twice so that's wrong only one copy of that data should be used by B so we need some way for B to detect ah this frame is the same as the previous one I got let's ignore it that's what we need so we need B to say discard that ignore that frame because if it didn't ignore it it would process that same piece of data 2 times it can ignore and then send back an act indicating that data has been successfully received the problem is how do we know that this one is a copy of the previous one it's not just intended to be the same and the way to know whether to ignore it or not we need sequence numbers inside these data frames so that we can know this is the same as the previous one but we have timed out in the lecture so you'll go and study that and we'll continue with that and introduce sequence numbers into these frames so that we can detect this case it's a strange case that if we don't ignore this we'll get an error