 We know we know the purpose of flow control is to make sure our sender doesn't send too fast for the receiver for both Stop and wait and for sliding window. Okay, it's both of them. That's the aim. Make sure we don't send too fast Because the receiver if it has limited space to store what it receives If we send too much before it processes the data it receives it will lose some data and We saw stop and wait is very simple where we just send one data frame and The receiver tells us when it's ready to receive the next one by sending back an act frame an acknowledgement saying Okay, I've received your data. I've processed it. I'm now ready for a new frame So it sends back an act to say that an acknowledgement but Stop and wait can be inefficient in some cases because what happens is we send one data frame if the propagation Delay is large then the source spends a lot of time waiting for an act to come back Time spent waiting time spent not sending across the link So that's inefficient because we want to send as much data as possible across the link. We want to use it all the time So sliding window flow control is a variation or in fact a superset where We allow to send multiple frames before waiting for an act So very similar instead of sending one frame wait for an act send a window of frames and then wait for an act Where this the size of the window may vary? still The aim is to do flow control don't send too much to overflow the receiver Where too much is defined by the size of the window? so The window at least the maximum window is an indicator of how much the receiver can receive Sliding window is more complex than stop and wait because we need to now keep track of which frames have we sent It's not just one frame one one data one act We may send a set of frames and receive multiple acts now So we use sequence numbers in the in each frame To keep track of the ordering of those frames frame one frame two frame three we and both the sender and receiver keep track of the sender keeps track of what it has Sent and what has been acknowledged Okay, that's this set of frames. So at some point in time I have sent some frames and I've received the act back that dumb and I may have sent some frames like six and seven but I'm waiting on the act So I just sent those two frames. They're out on the link. Maybe they're acts coming back I haven't received it yet and Because we're allowed to send multiple frames the window indicates how many more I'm allowed to send I haven't sent them yet, but I'm allowed to because the window Allows us to send up to some maximum number of frames the maximum window size and All the frames beyond that I'm not allowed to send so we keep track of those four sets of frames Those that are done those that have been sent but not act Those that I'm allowed to send and those that I'm not allowed to send and The way that we can keep track of that is to store three variables at the source These three variables the variables really are Some indicator of the split between these four sets of frames that is this point this point and here So commonly we can think the last frame transmitted It tells us the split between here the last sorry the last frame acknowledged here The last frame transmitted frame seven and The size of the window tells us Where the split is here so by storing values for those three variables This sender keeps track of what's happened in terms of sending data and receiving acts Receiver does effectively the same thing but from the perspective of receiving data and sending back acts and This is under the assumption that the receiver has enough memory enough buffer space to store W frames where W is the maximum window size If our maximum window is seven Then we assume the receiver has enough memory to store seven frames at a time In stop and wait the receiver needs enough memory to store just one frame at a time the one it receives So in sliding window, we need more memory at the receiver Which is a limitation of the protocol. It's a drawback What else? Again, we send data receiver sends back acts Sometimes called a receive ready message We'll see that there's a variation or a modification of the act either an acknowledgement or receive ready again, the the meaning is the receiver is ready to receive more data and We went through an example Showing how the perspective from A and B the source and destination change for those three variables the the last frame Act transmitted and the window size but graphically we see how as we send frames Our window closes Our window is the blue box. We send three frames means we're allowed to send four more as We receive acknowledgements Saying that the receivers ready to receive more our window opens allowing us to send more Send frames the window closes it gets smaller. We can send just three now Receive an act we can send one more because of the acknowledgement And we see this concept of a window sliding along and opening and closing as we send data and receive acts and similar at the destination what we See What we eventually go through today is well, how does this help with efficiency? How does this overcome the limitations of stop and wait? We'll see that today, but first a few more details about The acknowledgments the receive ready this just be careful. This is one specific example It doesn't always operate like this in this example the source sent three frames at the start Why three well? Just for this example, let's say only has enough data to make up three frames It's allowed to send seven at the start, but it only sends three Why well one reason because it only has enough data to send at this point in time to make up three frames So just in this example in another example if the source had a lot of data to send Maybe it would send zero one two three four five six send all seven frames at the start So just in this example Later it sends four frames one after another So the window indicates what you're allowed to send Of course what you actually send must be less than or equal to the window But it depends upon how much data you have at that time The other thing is What about the acknowledgments? When do we send an act or a receive ready message in this example be? Receive three frames and then sent one acknowledgment Which is a bit different or strange from what we've seen in the past at least with stop and wait Stop and wait one data one act here Three data frames received one act comes back It doesn't have to happen like this Just in this example. It could have been Received the first frame send back an act Received the second send back an act the third another act. It could have been like that Sliding window doesn't deter doesn't say which way it should be it depends upon how someone implements it So some products may do one act for every frame Some may wait until they've received a set of frames and then send a single act in this case What's the difference? Which one's better? Send one act for every frame or as in this example Receive three and send one act What's the advantage of say this one compared to sending one act for every frame? Lower overhead now if we think of the the link going from B to A Here receive three frames send one act if we had the alternative send an act for each frame would send three acts So across this link There's the option of sending a single act or sending three three acknowledgments These acts don't contain data They are overhead they are They reduce the efficiency of the usage of that link because the more time we spend sending acknowledgments The less time we have Available to send data say from B to A This just shows data from A to B, but at the same time B may want to send data to A So the the fewer acts we send the better So that's why in this case It's it's it could be better to send a single act than three acts now Sending one act for three is a little bit more complicated because we need to determine. Well, when do we send this act? Do we send it after the third frame? But what if we just receive two frames and a third one doesn't arrive? So it becomes complicated when we want to determine the best way for responding with an act But just be aware that there are different variations of it possible Now how does it work this act and it's common in many protocols not just this one that an acknowledgment Includes a number Where that number indicates the next sequence number expected? So be received zero one and two It sends back a receive ready an act saying I now expect three it doesn't say It doesn't send back an act number saying I've just received zero one and two or I've just received zero. I've just received one. I've just received two. It says what's the next value expected? And it has the same effect, but it's easier because if We receive an act saying I expect three That implies everything before three that has been sent has been received and acknowledged Because we do things in order if I send zero one and two A has sent zero one and two and it receives an act saying be expects three Then that must mean That be received zero one and two Because if they hadn't received zero one and two if they hadn't received two for example, but just zero and one They wouldn't send back receive ready three. They would have sent back receive ready two So this is a common way to to acknowledge data Tell the source. What's the next number you expect? Okay, so that's the basics of sliding window Let's now move on towards the efficiency Why can sliding window be more efficient than stop and wait? Why is it more efficient or why cannot be more efficient? send more data in in what time in send more data So be more specific you're on the right track Send you get to send more data potentially in the time it takes for an act to come back With stop and wait you send one data and you must wait for that one act to come back With sliding window you can send a window size of data Before you have to wait for an act to come back So you you have the potential to send more data before waiting for the act to return in other words you can Spend more time sending data as opposed to waiting for the act which is more efficient This is a joint class ITCS section. So there's many seats down the front. You're welcome to sit down here Last week when we introduced stop and wait we had some example where someone came out the front and I sent them data and overflowed them and then we use stop and wait and Saw that with stop and wait we we control the flow of data at the receiver and it avoids overflow Let's have an example of sliding window and we need some volunteers. Okay, the people who just come in late good I'm going to be the sender You're the receiver just stand up Stay where you are though I'm going to send my data to you. I'm going to send data to the risk to the destination and they're going to send back acknowledgments. These are our acknowledgments. Okay, we'll use these as acts this time and They have numbers on them and you just arrived late, but remember the key point when you receive data You're going to send back an act for every data frame you receive and The number of the act will be one more than the data you receive if you receive zero send back a number one If you receive two send back a number Three easy. Okay, I'll hold on to them. You'll need them all well So he's got acts that is going to come back to me now The the benefit of sliding window arrives when the Propagation delay is much larger than the transmission delay So we need a large link You're on the link Stand up to stay where you are, but stand up and get ready. We need to form a link back to our destination. Okay Just stay where you are. Yeah Stand up and stand up You're our link Because I cannot reach the destination I've got my data and what I'm going to do quite simply is Send the data so I'm the transmitter. I send the data and these Six people in the middle are our link and What they're going to do is receive the data just pass it at normal speed to the next person It'll be received by the destination When the destination receives the data, they'll see the sequence number and send back an act Okay, any questions on what you're going to do We have six link. Well six people forming the link and one destination Everyone else will watch and observe and these are my data packets Okay, we have a sequence number on there. In fact, we don't need a sequence number because in the first case I'm going to use stop and wait. I Have a lot of data to send okay But let's use stop and wait So I can send the data quite quickly to the first onto the link and let's try I've got more data to send. I want to send it. I'm waiting. I'm waiting Here I am as the source and I have nothing to do Until I receive the act saying thank you the next number I expect is one In fact, we don't need sequence numbers in stop and wait and then I would send the next data frame And I'm not going to do it because you know how stop and wait works and it takes a long time because what happened there is that I Sent the data and I spent a lot of time waiting for the act to come back Very inefficient for me because I spent a lot of time doing nothing Short time to transmit a long time to just send the act back all we need a long time waiting So now let's try sliding window Okay, and to keep it simple We'll have a window of three So let's say a two-bit sequence number So we're going to use sequence numbers zero one two three zero one two three. In fact, we won't go far and the source would keep track of The data that it sent and The current window size. So what's my initial window size at the start? Three okay, it means I can send three frames And let's do this slowly. So frame number zero I send and frame number one keeps You're the link and frame number two and Now I know I've sent three. I haven't received an act yet. My window is now zero. I cannot send any more So I'm waiting for an act to come back and in fact, I'll eventually receive three acts We'll get a bit complicated at the receiver. It's a long processing time at the receiver. It's a slow computer back there Actually, there'd be one act coming at a time one Following in the other And as you put the act in there when I receive one act I can send one more data We have an error in the link here and I receive the next act It's a full duplex link. They can go both in the same directions and this is a zero Sorry, I don't have the number on it and I received the third act and I will send Whatever the next number one every time I received an act in that case. I could send one more frame Just pause just stop for a moment Okay, well, let's pause our link but what what happened there the main point is that At the start I sent three frames So I delivered three frames to the destination Then I had to wait for the act to come back So we'd stop and wait for the time to get the data there and get an act back I delivered one frame With sliding window the time to get the data there and get an act back. I delivered three frames So three times more efficient because I've delivered three times more data to the destination In the same amount of time because With this same length link to get the data there and to get the act back It's the same time whether we're using stop and wait or sliding window How many frames What's the window size I need to be maximum efficiency? Note with the sliding window there of three frames I sent three and I still spent some time waiting slow processor long link. I Still had to wait for the act to come back So I sent and then waited a long time How could I increase the efficiency? How can I ensure that I wait zero time first one increase the window size? So in the I sent three frames my window was three if I had a window of seven I would send seven frames. I'm not going to try will become too hard if I send seven frames Then I spend most of my time transmitting What if I sent 100 frames a window of 100? And I think if we did it we'd see that I'd be sending the 10th the 11th frame the 20th frame and so on While I'm sending those frames eventually the act would come back For the first frame So I'd send the first one and then then all the others and eventually the data would arrive the act would come back When the act comes back. I'm still sending the window and Remember whenever I receive an act I can send another frame And if we have a window large enough it will turn out that I'm always sending Never waiting and that's the best case we can achieve the best case efficiency and You need to be able to calculate that so let's thank the our link and our receiver and Let's try and calculate the efficiency. Did you consume the data? so the The advantage of sliding window can be that we spend little time waiting for the act to come back Especially when we have a large propagation delay the example and I think it's in your lecture notes I hope very much. It's in your lecture notes that I printed out if you just go to the end of this To the end of this lecture Yeah, at the end of this lecture there's a Two pictures of sliding window which we'll use as an example. I'll show them on the screen The file is I think a sliding window example on the website. Let's see if I find it first This one So it's the at the end of this lecture in your lecture notes. There's a separate file on the website if you want to see This is an example we'll use to illustrate how The efficiency of sliding window can be determined. Let's make sure you can hear So make sure you can see this one I have color you can I'll show two cases here and we'll look at the Timing for sending our data using sliding window and then we can go through some examples of calculating To to speed this one up. I've done some calculations in advance. So let's make it so the For this example, I've set the propagation delay to be 200 time units Whether it's 200 micro seconds 200 seconds 200 milliseconds. I haven't specified. Okay, but 200 of something Just to keep things simple. I've omitted the units The units are not given but let's say we have a link such that the propagation delay is 200 and we have a data frame Which takes some time to transmit and in this case We say that the total time to transmit the data is 100 time units which consists of 90 of 90% of that is the real data 10% is header So just to keep things simple. I haven't given the actual data size in bytes But just the data transmission time which you would calculate normally and The act takes 10 time units to transmit. We have a two-bit sequence number so inside the header of each data frame and Inside the act in some cases Also inside the act we include a two-bit sequence number two bits, of course value zero up to three in decimal we include them in there and With a two-bit sequence number the maximum window size we have available is three So I'm one of the slides the general formula is the maximum window is two to the K minus one K is two in our case. So the maximum window is three Meaning we're allowed to send three frames and then we have to wait for an act to come back so what this diagram does is Draws the sequence of frames that you've done before with stop and wait in this part but I also on the left keep track of the The window from the perspective just of the source. I haven't drawn it for the destination B We're also in reality that B would keep track of this information as well But just to keep it simple. Let's focus on the source A And I've tried to color code it and you'll see at least the shading in your printout Remember we have four types of or four sets of frames from the source. We have the frames which I've already been transmitted and let's go back to the lecture notes to see that We have To the left the frames which are already transmitted that done finished We have here the frames which are Outstanding that is we've sent them. We're waiting for an act to come back Then we have the window which are the frames we're allowed to send and the rest of frames which are not allowed So four sets of frames and I've color coded them here. Although. I haven't drawn to the left The gray ones will see eventually are those which have finished completed those which I've sent and received an act for The green ones are the window those that I'm allowed to send The red ones are those that have been transmitted, but not yet act and The ones to the right the white ones. I'm not allowed to transmit yet And this is all determined by the windowing mechanism at the source with a Maximum window size of three initially. We haven't sent anything our window is three if we start at frame zero We're allowed to send frame zero one and two So at time zero when we start this we're allowed to send three frames this assumes we always have data ready to send and We're also going to assume eventually that the destination be always sends one act for one data frame received so At the start we're allowed to send three frames. Let's start sending them So we can only transmit one at a time. So we start transmitting frame zero. We're transmitting as Soon as frame zero is transmitted out of the source a it starts transmitting frame one and then frame two and After transmitting frame zero was we'll see that the window Will change such that zero becomes a frame which has been transmitted, but not yet act While the window covers one and two the window size is two The window size is the number of frames we're allowed to send it covers those two frames Frame number one frame number two. That's after sending frame zero and Then after sending frame one Zero and one are transmitted red Two is allowed to be sent. So then we start sending two and eventually zero one and two are those that have been transmitted But we haven't yet received an act and the timing will be such that Because each data frame takes 100 to transmit three in a row will take 300 time units So we go from zero to 300 here, of course those frames propagate across to be We transmit them and they propagate across the link and are received at the destination and it takes three sorry 200 time units to propagate Which means frame zero? We started transmitting at zero finished at time 100 It will be completely received by be at time 300 100 plus the propagation of 200 brings us to 300 So be receives frame zero at time 300 In this example, we're going to assume that as soon as be receives the frame it immediately processes that frame and sends back an act and that's Receive the frame. There's no waiting here. There's no processing time. Let's say it's a very very small Immediately send back an act the act takes 10 time units to transmit. So we'd finish transmitting at time 310 and the act needs to propagate back and Will arrive at time 510? So that's the act for the first frame frame with sequence number zero So from the perspective of the source We're allowed to send three frames. So we transmit that those three frames after transmitting those three frames We've sent our window size We're limited now. We cannot send any more This is the flow control mechanism That is we're not allowed to send too many to overflow the receiver in this example too many is more than three And we're limited to sending just three at a time So we send the three and now at time 300 we're waiting This is the time which is inefficient We're waiting. We're not sending anything. We're waiting for the act to come back We're waiting and then at time 510 we receive an act and the reception of an act and in this case What would the act number be The in the in the acknowledgement or on the other slides was called the receive ready. There was a number The acknowledgement number or the receive ready number What would the value be in this what first act that comes back? Be careful if we this frame is zero The act is just for this frame zero It's different from the previous example where we sent three frames and got one act here For every frame received B is going to send back an act So for frame zero received B sends back an act and the number in this act would be one Because the acts indicate the next value expected not the current one received the next one expected so it says thank you for that data I now expect frame number one and All right, we'll come back to here at the moment because in the meantime Frame one arrives at B At time 400 is that right? Yeah 400 Frame one finished transmitting at 200 propagation of 200 transmit the act. This is the act for frame one It takes 10 to transmit we finish transmitting at time 410 and we send the act back and the act number is two Because this act acknowledges frame number one by saying the next one I expect is two and you'll see at time 500 The second frame will be fully received and the act would come back. We'll look at the act coming back in a moment the Okay, the act comes back the first act act number one It acknowledges well, let's look at a a has sent zero one and two has not yet received an act for any of them Then it receives an act saying the next number expected is one Which effectively means frame number zero has been acknowledged? It's been successfully received and the receiver said, thank you. Let's move on so from the windows perspective when we receive this act Frame zero becomes one of those which has been sent and act Frames one and two are still outstanding That is we've sent them. We're still waiting for an act at this point in time. We haven't yet received the act Because we receive the act for one frame our window grows the green part is our window It grows so that we're allowed to send one more frame Every time a frame is act We can send another frame so Three is allowed to be sent now and at the same instant once we know that three is allowed to be sent Because we have enough data we transmit frame three So we start transmitting frame three and Once frame three is transmitted then would change to the state where zero is done one Two and three are outstanding Outstanding in terms of we've sent them, but we're waiting for an act still any questions before we scroll down So we're going through another example of sliding window And we're going to arrive at a calculation for the efficiency and compare it under different conditions Let's keep going So at time 510 we receive an act allowing us to send one more frame. So we send that frame Which means we're not allowed to send any more until we receive another act We're sent frame three Know that this link is Full duplex what that means is that a can be transmitting frames and receiving acts at the same time Haven't said that before but we assume that we can be sending and receiving at the same time so we're transmitting frame three and While we're transmitting that it's behind here at time 610 because act two Was sent here it eventually arrives at this time. We receive the second act and The first act had had act number one the second one would have act number two here We receive that act meaning With act number two frame one is done Because as you can see this act acknowledges frame sequence number one So frame one is done Meaning we're allowed to send one more frame So we transmit that frame frame zero and now two three and zero are outstanding We're waiting for the acts for those three and And then eventually the third act arrives Acknowledging frame two Frame two is completed. We're allowed to send one more. We start sending frame one and when that's done Three zero one are outstanding our window is closed. We're not allowed to send any more Because we've got three frames outstanding and the maximum window is three so Because our window is closed We're not allowed to send any more frames. We now have to wait again wait for an act to come back and Frame three was transmitted It propagates to the other side B sends back an act that acts going to arrive at ten thousand and twenty and you can calculate that Times six ten plus two two hundred for propagation Plus ten for the act plus another two hundred to get back What's the act number of this one what's the act number of the fourth act received Try and write it or work it out the act number for all of those acts You can write it on your slides on your picture If you scroll forward This picture is in your lecture notes It's on the front page, but it's also the end of the topic on flow control and error control right the act numbers so when the acts come back Indicate the number of that the acknowledgement What are these act numbers if you scroll through you'll find it inside the lecture notes as well Remember the acknowledgement numbers It's not shown on this diagram. These are the acts the acknowledgments The numbers included in those acts Indicate the next number the next sequence number of data expected so The first sequence number received was one of sorry was zero So the act number here would be one if we receive zero the next number expected is one Should be in order Then we receive one the next act here would be two We receive two the next act number would be three We receive three the next act number is It's zero Remember with our sequence numbers. We're limited to zero one two three zero one two three We only have two bits available. There's no four We wrap around So when we receive frame with sequence number three we send back an act saying thank you I now expect frame with sequence number zero because that's the next one in this sequence So this would be zero one and two and in fact, I think we reached the end that We receive an act With act number zero Saying frame three is done. I'm allowed to send one more. I Send that one. I've got three outstanding zero one and two then I receive another act and That allows me to send one more frame and Then I'll receive another act and it's not shown here. I stopped the diagram, but it keeps going I'd be able to send another data frame and Then if you follow that we'd have to wait because we'd have three frames outstanding And we'd have to wait for the next act to come back. Can you see the pattern in this case? If we if we continue drawing this if I ask you in the exam, here's the scenario We have a thousand frames Of course, you're not going to draw the entire set of one thousand data frames Because you should quickly see that it's just repeating Window was three we're allowed to send three frames and then we have to wait for the act to come back and The first act arrives back allowed to send one more But then the second act comes back So allows to send one more the third act comes back allowed to send one more we've sent three Now we have to wait again because three is the maximum we can send before waiting for an act So we wait we wait receive an act One two three sent again wait three sent and if you keep going we'll see that this pattern of Transmit three data frames wait for the act for the first one to come back and then transmit another three frames Wait for the act for the first one to come back and so on it just repeats Any questions on on this procedure with our sliding window flow control? in the case where we have Always have data to send So we've always got something to send and we're always sending one act for one data frame received With zero processing delay to keep our calculation simple So we care about the performance when we use this protocol Given this link how efficient are we in using this link? Well, we see every 510 time units zero to 510 510 to 1020 so again another 510 time units Every 510 time units We're sending three data frames Therefore B is receiving three data frames So what fraction of the time are we receiving real data and it's down the bottom of the slide, but let's Make note I won't write units just to keep it simple. We receive three data frames every 510 time units Now each data frame if we go back to the top each data frame The data transmission time of 100 Consists of 90 time units of sending real data and 10 of sending the header So 90% of the time when we're sending a data frame. We're sending real data So in every 510 time units, how long are we sending for what time are we sending real data? Three data frames each we transmit real data for 90 time units every 510 time units 270 over 510 that is We're sending real data and therefore receiving real data every for 270 time units every 510 time units The other 240 time units were either sending header or we're waiting So that's our measure of efficiency Efficiency is what fraction of the time are we delivering real data to the destination? Did I get it right? 3 by 90 times 510 down the bottom 52.9 percent So with this sliding window protocol with a window of three Using this link under these conditions. We get an efficiency of 52.9 percent Quickly calculate. What would you get if you use stop and wait? Okay, spend a couple of minutes Assume you use stop and wait flow control in this case same conditions You don't have to draw the picture. You should be able to quickly calculate What's the efficiency if we instead use stop and wait? Try Not sliding window with a window of three, but just stop and wait which really is a window of one Stop and wait remember it would look like send a frame do not send the next two, but just send one frame Get an act back send the next frame get an act back What's the efficiency in that case? Anyone have an answer? Stop and wait one frame wait for the act What fraction of the time are we sending real data? 17 sounds about right 17 percent See if you can arrive at that About 18 percent. Yep, 17 18 percent There's a bit more time for others to see if they can get that answer So stop and wait. In fact, you'll see the same timing, but just remove these two frames You don't have to draw it, but that's the concept and from there you can calculate How much time do we spend sending data? Every x time units we will yeah With stop and wait we see so imagine one and two would disappear would see that one frame Act one frame act and keep going forever and The timing would be the same that is the time to receive the act back takes 510 time units Same as with a sliding window because the link characteristics are the same the data rates are the same and We're only delivering one data frame in that time And each data frame So with sliding window we delivered three data frames in that time with stop and wait just one data frame and each data frame We spend 90 time units transmitting real data 90 time units spent sending real data and You do the calculation and it's in fact one third of This case Which is what 17 18 percent? 17 points something it's three times worse than our sliding window case And recall that stop and wait is just a special case for sliding window the window is one If we set the window to one we get stop and wait for sliding window because If the window is one it means we can send one frame and then wait for an act with a window of three We can send three frames wait for an act So stop and wait in this case is three times worse in terms of efficiency than our sliding window mechanism The advantage of stop and wait is that it's very simple The source and destination do not need to keep track of all these variables of what we've sent What we're expecting to receive the window size because there's just one frame involved each exchange also the amount of memory or buffer space needed at the destination is At least the size of the maximum window So with stop and wait the window is one we need buffer to store one frame at the destination at least With our sliding window with three frames B needs buffer space or memory to store at least three frames. We need more memory Okay, one threat one frame versus three frames is not much difference in terms of memory But in practice at least in older devices and or very cheap or low cost cheap or small devices Where memory is limited Then it can be a significant difference in cost in in in processing if we need much more memory at the receiver So the advantage of sliding window here is efficiency The disadvantage of sliding window is that it's more complex and you need more memory at the receiver next page same scenario same setup except we've increased the window up and up to Seven we have a three bit sequence number So effectively stop and wait The window is one the previous case we calculated for a window of three This one was a window of three now. Let's change the window again up to seven So three bit sequence number and you can go through and see what happens initially Is it shown? At the start a is allowed to send seven frames B must have buffer to store at least seven frames We send one frame so we start sending those seven frames Zero one two and so on after sending the first frame we allowed to send six more so we send frame one frame two frame three frame four After sending frame three we've sent zero one two and three we're allowed to still allowed to send three more frames You see if you the size of the red and the green parts is always seven in this case Now if you look at the timing And recall I made a mistake in one of these numbers. We'll see that later 100 200 300 400 500 at time 500 we've finished transmitting for we start transmitting five We're allowed to send five So we start sending frame five Then at time five hundred and ten we receive the first act back Because the act for frame zero with act number one eventually arrives back so After at least after starting transmitting five Zero to five would be outstanding, but then we receive the act back meaning zero is done Zero has been successfully delivered Which allows us to send one more? Every time one frame is act. We're allowed to send one more frame So when this act comes back We're allowed to send also frame seven six and seven we transmit five we start transmitting six and while transmitting six the next act comes back and Allowing us to send one more frame frame zero in this case Because zero and one are acknowledged there's some outstanding and we're allowed to send two more in this case and We'll see we transmit a frame and then an act comes back for one of the previous frames Every time an act comes back. We're allowed to send one more so we transmit one But then another act comes back allowing us to send another one we transmit another act comes back Send receive act send receive an act We keep doing that forever We've always got Some frames which we're allowed to send that as our window the green part is always open There's always some frames in the window meaning we're always allowed to send more frames and because we keep receiving acts for the previous ones we Just continually Continuously send data frames There's no time waiting for an act Because the window is large enough such that We spend all the time transmitting while we're waiting for that hack No time waiting Always transmitting So this is the best efficiency that we can get we cannot do better than this 100% of the time transmitting in this case The only overhead is the header inside each data frame Although we're always transmitting data frames Each data frame this is with a window of seven Always transmitting so we won't calculate here always sending data always receiving data But of that data there's 90 of real data and 10 of header That was in the startup of the start of the question so 90% of the time we're transmitting real data 100% of the time we're sending data frames 90% of the time we're sending real data our efficiency is therefore 90% and that's the best we can do in this case so We've achieved maximum efficiency under these conditions We're using the link all the time to send our data. The only overhead is the headers The only way to improve the efficiency to go above 90 is to reduce the size of the headers or increase the size of the data inside the frame But usually that's controlled or fixed Any questions on how we calculate the efficiency in this case? We don't look at the total time for to get an act back because it turns out we're always sending so we simply look at if we're always sending we look at the amount of header that we spend sending so 90 of real 10 of header 90 percent efficient 90 percent of the time sending real data and Just to remind you that come from the setup of the question at the start. We said each data frame Takes is 90 percent time sending data 10 percent of the time sending real sending the header if it was 80 20 Then we'd be 80 percent efficient if it was 95 5 would be 95 percent efficient So we see by changing the window size. We improve our efficiency up to some maximum What's our efficiency if the window is 15? For bits What's our efficiency if the window is 15? Increased more how efficient will we will we be in this case? 90 we cannot go better than 90 good We we cannot send any faster than what we're doing now So increasing the window further doesn't help in terms of efficiency. In fact, it just adds An extra size in the header for the for the sequence number to be included so there's some optimal value for the window in this case and Seven in this case In fact, you may find it's slightly different than seven. I've used window sizes which are When we have a K-bit sequence number I've taken window sizes the two to the K minus one in practice. You could use different window sizes ten nine There's just common to have a maximum window size which depends upon the sequence number Did anyone see the error in this picture? What's the problem? 510 is correct the 700 is incorrect. I think it should be 800 there I don't know why I even included it's not so relevant, but you can check this would be 500 600 700 800 900 and so on so this should be 800 at that point But it doesn't impact upon our our calculation Efficiency 90% the only overhead is the header The best we can do let's go back to our slides summarized and then we'll have a break so In general with sliding window the window controls how much we can send so that we don't overflow the receiver and It depends so what we actually send depends upon how much data we have available and when the axe come back So we have one example. We went through here The example we went through just a moment ago and calculated the efficiency that was for a case when we always had data to send So when we always have something to send and there's always acts coming back. We calculated the efficiency That's the maximum efficiency we can achieve of course in some cases in reality, we may not have data to send and If there's no data to send of course, we do not send anything and the overall efficiency will go down so if you want to calculate the Efficiency that we can achieve with this sliding window protocol Then make the assumption that we've always got some data to send This is the the two examples. We went through so this is the setup that question except I just put the numbers in so I think if you do the calculations, you'll see that the data is 90% The header is 10% the act frame is this 10% or 10 units and The propagation is 200 units. So it with these numbers you get though the example we just went through With a two-bit sequence number and a three-bit sequence number Let's just finish with a couple of extra features so Both stop and wait sliding window send data wait for an act how much data would do we send depends upon the window There are a few more Additional features optional extras that you can use with sliding window There's a optional receive not ready frame That is the receiver when it receives data may send back an act But includes a number in there indicating don't send me any more data yet. So It doesn't allow the sender to Send more data frames and the way to do that is simply to set the act number to be the same as what was sent in the past So there's this optional value optional frame type and It comes important when we do this other thing called piggybacking in the examples We've looked at we've only considered data going from a to b in a real link There's usually data going from a to b and data going from b to a in both directions in that case We would use separate instances of the sliding window or stop-and-wait protocol So a would keep track of what it's sending to be and separately B would keep track of what it's sending to a So we have data going from a to b acts coming back and Then the other direction data going from b to a and acts coming back In that case piggybacking is the concept that to save in how much we send We can combine the data and the acts into one frame Just quickly what that looks like So here's an example where a sends data to be B sends back an act and then B sends some data to a and a sends back an act Okay, that that may be a scenario that arises piggybacking is when we want to send data like that But what we do a sends some data to be B sends back an act for that data But in fact includes that act in the same frame as the data So instead of sending two frames act and then data Send just one frame Which contains the information of the act as well as the data that B wants to send a this is the concept of piggybacking And it reduces the overhead a little bit Because if we used our numbers the act was say 10 time units the data was 100 which included 90 Plus 10 of header Normally the header we can include all the information of the act So if the head is designed in such a way that We don't need extra information for the act we include the act number inside the header of the data So when we combine them we actually send for just 100 instead of sending for 10 plus 100 We send for just 100 giving a small reduction in how much time we spend sending So that's the concept of piggybacking And it's common in in protocols Combine the data and act Into one frame. What's the last two points if no data to send okay, that's related to piggybacking if If we don't have data to send like a in the third case doesn't have any more data to send to B Just send a normal act if there's no new act That is if we send data and then send Excuse me send data back if there's no act to send back then we can include the old act number which Is combined with piggybacking? I think we don't need to understand that at this stage in later protocols We may see examples of that So main point here piggybacking is the concept of combining a data and an act frame into one frame and finishes for flow control The two main mechanisms stop and wait and sliding window The next thing is error control. What happens when we lose data? And we'll see that well we retransmit we send our data if it doesn't arrive at the destination If we don't receive an act back then resend the data that we sent previously as a as a way to Fix errors to fix the loss of data. Let's stop now and Have a break and at 1040 or we'll have not a lecture, but well, let's say a tutorial