 Flow control is a mechanism to make sure that the sender doesn't overflow the receiver and It's needed in the cases where the the sender is has the capabilities to send very fast But as the receiving computer receives the frames containing the data it takes a long time to process them and What may happen is if the receiver receives too many in a short period of time it overflows because in fact the receiver has some memory Allocated to receive the frames if it fills up it cannot process or receive any more That memory we often refer to it as a buffer. So we've actually have gone through two Protocols so far. So let's just remind you of those protocols. I Think there's no need for you to draw them really because we've drawn them before but just so I can quickly remind you of what we've considered We've had so if we want the first protocol that we considered we have a and b we had but say the sender and receiver and Quickly what happened the very first one we had the rule where the sender just sent The sender sent with no feedback from the receiver. So we we had a picture like this We had frame one frame two and so on the sender keeps sending one after another and this those frames propagate across to the receiver and When the receiver receives a frame it processes it and once it's finished processing it can move on to the next one Now in this protocol, there's no feedback Now let's assume that the buffer space At the receiver is large enough to fit one frame. I think you've drawn this picture before But let's consider what happens if there's just one frame just in Enough memory to store one frame at the receiver what that means when the receiver receives a frame it puts it into the buffer and then Starts processing the frame it takes some time. It depends upon the the computer when it's finished processing It removes the frame from the buffer and can move on to a neck the next one here We have buffer space for one frame So initially the buffer If I draw it here. Here's our buffers space for one frame It's empty There's nothing in it But when we receive the first frame at this point in time We put that frame inside the buffer Say the buffer is full The buffer is a memory for to store one frame Initially, it's empty and now when frame one is received It's it's full we store that frame in the buffer and we start processing that frame Let's say it takes a long time to process. We have a very slow computer maybe it's gonna The time to process that one frame is going to take us down to here would finish processing at this time Now what's happened? this first frame has Been received put inside the buffer. It's still in the buffer while it's being processed So we're processing here But then the second frame arrives At this time what happens to this second frame Where does the receiver put that second frame? It cannot put it in the buffer with a buffer Only has space to stick one frame. It's currently full. So the second frame arrives. We cannot put it in memory So we can't put it anywhere So we discard or drop that frame the receiver the The receiving device receives the bits but doesn't save them in memory. It discards them essentially That frame is lost It's as if we didn't receive it when we discard it And that's our problem with flow or the problem and the motivation for flow control if we have buffer to store a certain number of frames and We receive more than we can process Such that the buffer becomes full Then we lose frames which are transmitted and that's very wasteful because the sender sent this frame It was actually received but because we have no memory space We couldn't do anything with it and we had to discard it and eventually they have to be reset and that would be a problem So this simple protocol of just sending can cause overflow So we went through a second protocol called the stop and wait flow control protocol where we saw a data and Whenever receiver receives data, it must send back an acknowledge Just remind you of that one Still have a buffer of one frame We transmit that frame there's some propagation delay and the procedure was our buffer Let's draw it A buffer isn't originally empty We receive the frame here. So the buffer becomes full We still got buffer space for one frame and then we process and when we've finished processing Note that the sender after sending that first frame is not allowed to send the second one It must wait Stop and wait until it receives an acknowledgement back saying I'm ready for the next one This is how we achieve flow control with stop and wait. We'll never overflow the receiver Because the sender will only send After the receiver tells it it's got space to receive one more So in this example we receive the frame put it in the buffer process the frame Eventually we finish processing Say we finish here. So the buffer becomes empty We take that frame out. It's done We've processed the data. It's finished and that triggers us to send back an act saying Really, thank you for the data. I'm now ready to receive more because I've got space in my buffer and Then the sender can move on to the second frame. So this is how we can achieve Flow control will never overflow the receiver's buffer because we'll never send One when it has the buffer full Data act and if we keep going data act and so on So this is good for flow control. What's the problem that we saw with stop and wait? Had what problem We calculated some numbers in your last lecture have a look at your lecture notes. You'll see the problem Wasting time right inefficient That is the sender Transmits under some scenarios Especially when there's a long propagation delay We transmit and then the sender spends all this time doing nothing It's sitting there not sending we have a link We want to send across the link as much as possible But if we have a long propagation delay, especially or a long processing delay Spend a lot of time not sending and then we can be very inefficient with the data transfer That's the problem with stop and wait It provides flow control, but in some conditions. It's very inefficient and we did a few calculations of that last lecture The concept of improving upon the efficiency And I'll roughly draw it here We saw that the sender spends a lot of time not sending The concept we'll use is to say Can we allow the sender to send? Instead of weight there that is what we'd like to do Is have a different protocol that allows the sender after sending the first one to send a second one Maybe a third one and we'll see that's the our new protocol will look at today We don't want to have to spend all this time not sending. So what if we allow it to send a few more? Well, let's let's say a few more in this case. Let's say we allow it to send three frames before it has to wait for an act in that case The sender sends the first frame the second and the third and then it stops and waits for the act to come back What about the receiver? If the receiver is slow to process the first one a game will have an overflow when we receive the second frame So we don't get flow control here But if we expand the buffer Then we can still provide flow control if we have a buffer of now three frames It's initially has face for three frames. We receive the first. We put it in the buffer. We're processing the first frame In the meantime, we receive the second frame put that in the buffer and Receive the third frame put that in the buffer while we're still processing the first frame and When we finish processing the first we can still send back an act saying I'm ready for one more and that will Be allow our source to send the fourth frame and that's because we'll have space in the buffer because the first one Have been has been removed So our extension of the stop and wait flow control protocol to overcome the inefficiency Allow the source to send more than one and we'll put a limit on it W will say a parameter called W and It will give us more or higher efficiency but There's two problems with it. We'll see one is that the receiver more needs more buffer space more memory used is a negative of this new protocol we need at least enough space for three frames in this example if we Expand this limit to maybe five frames. We need buffer space for five frames and We'll go through the protocol now and you'll see at the end of the lecture It's much more complex than stop and wait and that's an another negative of it. It's how implement in the devices so it can be more efficient, but More memory required and more complex So let's go through it now. So we'll return to the lecture slides and explain it this new protocol We call the sliding window flow control protocol first one to stop and wait to send one frame way for an act here We can send W frames. Where does it say W? Somewhere on the next slide. I think we are allowed to send it More than one frame will define as W as a parameter a window size of frames and That will provide better efficiency than stop and wait in the most conditions But as we'll go through more complex now One thing that's more complex is that we need to now keep will need to Keep track of the frame numbers So instead of send one the act data act we send many Get an act or get acts back and for this to work. We need to Keep the frames in order. So we'll give every frame a sequence number Inside the header of every frame will be a number that identifies that frame in sequence and Because the header we want to keep the size small will only allocate several some bits to that header and That will be defined by the specific Protocol or standard. So in general if we have a k-bit sequence number Then with k bits the values we can represent in decimal a zero up to two to the power of k minus one Let's explain that Let's say I have many frames to send. I have ten frames to send so I want to give them numbers to identify them uniquely and In the first example, let's use a two-bit sequence number and This sequence number is included in the header of the frame so the frames We'll talk about the first frame the second Third and so on So we have the ten frames The sequence number of the first frame if we're using two bits We start because we're using binary here. We start with zero zero Which in decimal is zero? Okay, so the first sequence number is zero Normally we can start counting at zero in this case So the the first frame inside the header would have sequence number zero I'm going to write the decimal value here, but it will actually be the binary value zero zero, for example in binary The second one would be zero one or one in decimal then two Then three The fifth frame. What's the sequence number? So fill in the sequence numbers for the remaining six frames What's the? sequence number given to the fifth frame What do we have the back corner? easy question For names have sequence number zero one two three. What's the fifth one? first four zero one two What is the fifth sequence number? Give me a guess The first four are zero one two and three. What is the fifth? Not four Okay, so that's the wrong guess Because we only have a two-bit sequence number We can only represent a value with those two bits. So we must We can't go to four because four in binary needs three bits one zero zero But we only have two bits available to store the value in the header So what we do is we wrap around we come back to zero so the fifth will be zero and One two three and so on And we can keep going so that's the idea with sequence numbers We only have a fixed number of bits available So we need to wrap around when we get to the end Come back to zero that is if we had a three-bit sequence number Start at zero with three bits Seven is one one one eight requires four bits So the ninth frame we'd wrap around to zero if we have a million frames to send we just keep going Incrementing the sequence number, but once we get to say seven here we wrap back to zero in the next sequence number So from now on in the sliding window flow control will allocate sequence numbers to the frames so it's a bit bit confusing because we talk about the first frame is Sequence number zero the second frame is sequence number one because we can't start counting at zero so we want to allow our source to be able to send more than one frame before it has to wait for an act and To do that correctly it requires the source and the receiver to keep track of What has it sent? How many more frames is it allowed to send within some limit and what has been acknowledged? So the main part of this protocol is how do they keep track of What's happened in the past and what they can do in the future. So we'll describe that and go through an example to illustrate it First let's look at the sender and we'll define a parameter here Say in our sliding window flow control is allowed to send up to W frames Before it has to wait for an act in Stop and wait flow control the sender was allowed to send one frame before it waits for an act here We allow it to send W frames where we would define W in advance for example. I may set it to three or Seven or some other number In this example will go through W is seven, but in other cases it can be a different value W refers to our window and we'll see the concept of the window come up in these examples So if W is seven that means the sender is allowed to send seven frames one after another After sending those seven frames it must wait for an act Before I can send the next frame now to to keep track of what it sent and what it's allowed to send Is it allowed to send one more or not? We have these three variables at the sender it keeps track of these values over time It keeps track of the last frame that has been acknowledged So at any one point in time we may have sent some frames and We have also received an acknowledgement back saying thank you that frames done So if we've had some frames acknowledged the last one that was being acknowledged We record the frame number or the sequence number the other thing we keep track of we may have sent some frames But we haven't yet got the acknowledgement back So maybe we've sent three frames But we're waiting for the act to come back So we'll keep track of the last of those that we've sent the last frame transmitted but not yet acknowledged and Because we're allowed to send up to W frames. Do we have any questions at the back? We have a volunteer for the next question Okay, good Not yet. I don't have a question for you Because we're allowed to send W frames without waiting for an act if we've sent if W is seven for example If I've sent three I'm allowed to send four more if I've sent two. I'm allowed to send five more The maximum is seven if I've already sent six. I'm allowed to send one more The number more that we're allowed and is called the current window size. So we keep track of how many more we're allowed to send so in fact we have a maximum W and We have a current window size We think of these as variables that the sender keeps track of the values that change over time To see how the protocol works will draw them on a picture like the one shown here Let's explain the picture in the same way as my frame sequence numbers We can think that okay the first to the tenth frame have sequence number zero one two three four five six seven zero And it just keeps going say we have an infinite supply of frames in this picture. We draw them in this in the square So a frame with sequence number zero one two three up to seven zero one two three and so on We've got It goes continuously in both directions What we do is draw this picture to indicate the state of these values these variables at some point in time We can think there are four groups of frames From our perspective at some point in time. There are some frames, which I've sent already and The receiver has already sent back at AK We can think those frames are finished. I've sent them the receiver sent back an axe saying thank you I've processed them Those frames are finished and we can really forget about them They've been successfully transferred We actually keep track of the last sequence number in that set of frames That's the last frame acknowledged and in this picture. It's in this example. It's five What that means the last frame acknowledged is frame number five Because we do everything in order if five has been acknowledged Then it means the one before it should have also been completed because we only acknowledge in order If five is act then so is four three two one and zero So we only need to keep track of the last one In this picture, I'll Indicate that we'll see in the example this vertical bar indicates to the left are the frames which are done everything's finished my sender may have Sends some frames. It's received the acknowledgments for some of those frames, but others it has not yet received the acknowledgment So we'll keep track also of the last frame transmitted, but not yet act in this picture Six and seven have been sent But we haven't yet received an acknowledgement from the receiver saying the process them So the last frame transmitted and not yet act is seven Six is also in that set Again in this example, we have a window size or a maximum window size of seven So if I have to send two frames Frame numbers six and seven and I haven't yet got an act We can think there is two outstanding. I'm allowed to send five more and That's what this light blue rectangle indicates the current window size is five frames I've sent to If I want to I can send five more these five I Cannot send anything beyond that Because the rules are I'm only allowed to send seven before I have to wait for an act to come back So really we can think frames which are done to the left of this vertical bar Frames which have been sent but not yet act six and seven frames which I'm allowed to send through to four the blue window and Frames which I'm not allowed to send everything beyond Five on the right-hand side So really those three variables visually we draw this vertical bar Five is last frame act and the blue rectangle to indicate the current window size The window size is five here and seven is the last frame transmitted as we transmit more frames And as we receive acknowledgments those values will change if I transmit frame zero You can think this blue rectangle Get smaller on the left-hand side We will think this blue rectangle will call it the window and as we transmit frames It will close on the left-hand side and As we receive acknowledgments it will open on the right-hand side and so it's a Something that's opening and closing like a window and over time it will move along so the name sliding window comes from that We'll get to it a detailed example in a moment The receiver does about the same but from the reception of frames perspective and transmitting acts The receiver has buffer space for seven in our example or W frames. It has enough memory to store W frames It keeps track of the last frame that has It has received and sent an act for It keeps track of the frames that it it has received but not yet sent an act for they are stored in the buffer six and seven in this example and It keeps track of that it may receive in the future That has buffer space for If we have a buffer of seven frames If we've received to we've got space for five more If we receive another frame, we have three in the buffer. We've got space for four more So the window indicates how much space in the buffer When the receiver receives data it processes the data and when it's ready for more it can send an act an acknowledgment In the in the next picture the act is called receive ready The the meaning of this acknowledgement is saying I'm ready for more So it's abbreviated to our are in the next picture Let's have a look at an example and go through the details of how it works So what we're going to do is consider an example where the source wants to send some data to the receiver And we're going to keep track of these three variables using such a picture At both the sender and receiver Here's our example We have a source system wants to send to the destination system B and just to keep remind you in this specific example We have What? We have a three bit sequence number So for this case we go from zero up to seven and then repeat and we have a buffer for seven frames At the receiver buffer space for seven frames And what the picture will show is that as we send data frames that denoted as F a frame from a To be those variables will change and as we send acts back and The acts are denoted as receive ready our are that those variables will change with the aim of Allowing the sender to send as many frames as possible, but not overflowing the buffer The buffer of seven frames Know that this is just one specific example In other cases that may not operate exactly like this. So we'll just see One instance of how the sliding window flow control works At the start the source system a the sender who wants to send data the initial state is The current window size is seven. We initialize it to the same size as the buffer So the blue rectangle indicates a is allowed to send up to seven frames It can send less but it cannot send more than seven frames before it has to wait for an act Let's say at the start that a User a has three frames To send so a has three frames. It wants to send to be In a different example, maybe it had four or one or ten, but just in this example. It's got three to send at the start Now the window size of a is Currently seven So a is allowed to send up to seven it has three So what it will do is transmit those three frames one after another and that's shown by these arrows in the picture Frame with sequence number zero is sent Followed by frame with sequence number one and frame with sequence number two We send our three frames from a to b and let's look at the change of the the variables at a after we send those three frames Before we were allowed to send seven The maximum we're allowed to send at any one time have outstanding is seven the maximum window We've sent three so we're allowed to send four more See our blue window has shrunk from seven down to four and the outstanding frames those which have been transmitted, but not yet act a zero one and two So this picture just keeps track of their current state at source a It tells us zero one and two have been sent Not yet acknowledged if we want We can send three four five and six. We can send another four We don't want to send another four because I only had three frames to send in this example I don't have anything more to send so I don't send anymore and then Since we have nothing to send we'll just wait and see what happens next Let's look at the destination B. See what happens there and Let's add in another thing on on B. Let's say the buffer space Buffer space if I can fit it in there. What's the buffer space originally at B? We say it's seven The buffer can fit seven frames. How much space do we originally have available? Well seven seven slots are available We'll keep track of the buffer space as we go over time Originally, we've it's empty. We've got seven slots available We receive frame zero We put it in the buffer So the buffer space is down to six. We receive frame one. We put it in the buffer. It's down to five We receive frame two put it in the buffer. The buffer space is down to four I'll just keep track here After receiving the third frame Three of them are in the buffer. We've got space for four more now from the variables for destination B It has received zero one and two and It's got space for four more frames which frames three four five and six the car a window at B Is four frames the window at B matches the buffer space What that means is that B? hasn't yet processed those frames maybe they're in the buffer and it's waiting to process them and Maybe in the future. It can expect to receive up to four more frames if a sends it can fit in more Four more frames into the buffer in this example. We're going to illustrate a slightly different operation to what we May expect when we receive a frame We start to process that frame and When we finish processing we may tell the source we've done we send back an act Now one approach is that whenever you receive a frame you start processing and when you finish processing that frame You send an acknowledgement back and When you finish processing the next frame you send back an act and so on for example B receives frame zero it processes send back an act it processes frame one sends back an act frame two sends back an act So that's one approach and We can use that in some cases But if we receive and process those three frames in a short amount of time sometimes it's More efficient not to send three acts Just send one act that acknowledges all three at once And that's what this example illustrates We don't send an act for each of the frames we received We will just send a single act receive a ready message Saying thank you for those messages. I'm now ready for more so This is a an extension or a feature that's commonly used We don't want to send too many acts because it creates more overhead So if we can send one instead of three that would be better We'll come to a different case later How do we implement that? So at this case three frames have been received. They've been processed. We're going to send an acknowledgement back saying those three are done Maybe at this time we can say We've finished finished processing zero one and two three frames So we want to tell a that But we only want to send one message to tell a that and the common approach to do it Send an acknowledgement or receive ready Instead of listing the frames with that have been finished We would tell a what's the next frame number that we expect to receive If we've finished zero one and two and we do everything in order the next one expected would be three So we see there's acknowledgement that comes back from B to A. They receive ready message Includes a value called in includes the value called the acknowledgement number and it has a value three This is confusing for some people But just remember the way that we acknowledge things commonly is to say Thank you. I now expect the next one and the next one in this case is three as Opposed to saying thank you for zero one and two we say thank you I now expect three and that implicitly acknowledges zero one and two So that's common in protocols when we send an act Tell the source what's the next number we expect from bees perspective? Zero one and two have been received They've been processed. We finished processing those three frames So they move into the set which are done Because we've finished those three we removed them from the buffer We had four four spaces available in the buffer That is we had three frames in it. We finished them remove them from the buffer the space now available is back to seven Had three frames finished removed from the buffer So we've got seven spaces available and we see our current window size is seven frames Receive three process three and acknowledge those three and from the bees perspective The window has moved along. It's sliding along questions so far I told you in advance sliding window is more complex than stop and wait It's more complex to explain and understand so We need to go through it slowly What's your problem? What question start with one If there's too many that's okay. Let's start with one All right There's a question about what happens if we send more frames. Well first remember what these pictures are showing Is the state of the variables at the source and destination? Now I say sending a frame. Well We send data frames from A to B. We send acknowledgement frames from B back to A. There's no data coming back and it's going from A to B And The currently we haven't got to this point yet. I think your question is about the next one So we'll get that in a moment, but currently what we see is we're allowed to send seven frames Without having to wait for an act That's what the blue window indicates that's how many I'm allowed to send I send three. I'm allowed to send four more I don't have any more to send so that's it Until I receive an act And from the destinations perspective, this is not how many it's sending. It's how many it's received It keeps track of what it has received. All right. I've got buffer space to receive seven I received three put them in my buffer. So now I have buffer space to receive four I process those first three so I remove them from the buffer now I have buffer space to receive seven again So at this stage all we're doing is saying Keep track of we're allowed to send and how much we Can receive It could have been different. What if we had 10 frames to send? at the start Well, we could have only sent seven of them The rules are you cannot send more than seven before you have to wait for an act Here we only had three though. We were lucky We'll come but maybe to some other questions down below. Let's finish this acknowledgement coming back B processes zero one and two that done send back an acknowledgement Denoted here receive ready the receiver is ready for frame number three I've done zero one and two. Please send me frame number three When a receives this acknowledgement It tells a Let's look at the previous state Previously a had sent zero one and two It knows what it has sent Then it gets a message back. I'm ready for three That tells a Zero one and two must be finished Because if the destination I've I have sent zero one and two the destination Ready for three So it means zero one and two are done so zero one and two are Have been transmitted and acknowledged And really this means I'm allowed to send three more I was allowed to send four but Three of three frames were acknowledged. So I'm allowed to send three more and our window size grows to seven We'll get on to the more another situation in a moment But just note the blue rectangle shows how many we're allowed to send at any point in time Or how much space we have in our buffer at the receiver Let's keep going and see the second part. I will Give you a chance to to finish the diagram in the third part So in the first part all of the example We said that a had three frames to send is sent them and they've been acknowledged. We can say they're done. That's finished Let's say sometime later A has four more frames to send The window size a tells it. It's allowed to send seven It has four to send so it sends those four frame with sequence number three four five and six and the status is that Three four five and six have been transmitted Not yet act We haven't yet got an acknowledgement back We're allowed to send three more if we want to We don't want to at this stage. We only have four frames So this is the status of a after transmitting those four frames Everything from two and below are done Three four five and six are outstanding Seven to one. I'm allowed to send if I want now. Here's something slightly different. We said in the previous example We received three frames and sent one act And that's a good idea every Instead of sending three acts just save in the overhead and send one to represent three acknowledgements but It depends upon the implementation and the timing as whether you send one act for three frames One act for two frames received or one act for every one frame received It's actually up to the implementation as to how to do that The problem is if we send one act for every three frames always Then the third or the second frame may take a long time to arrive and therefore it's a long time to send the act back So in reality The number of data frames we receive before we send an act may change In the previous case three data frames one act Now we see a case B receives one data frame frame three And then immediately sends an act Just to to make it more complex. We'll consider a different scenario here Let's see what happens when that occurs Previously B had seven a space for seven frames in the buffer Three through to one it receives frame one Puts it in the buffer and let's say it processes it very quickly Gets in the buffer the CPU is available so it can process it very quickly So in this specific example, we receive frame three and then send an act for frame three Saying thank you. I now expect what Four if I receive frame three Process frame three. I remove it from the buffer and I tell the Source a I now expect frame number four Okay, the next one expected and that's what you'll see. We'll see it when it gives back rr4 indicates B expects to receive frame four so Three is done After sending that act three is done The next one expected is four through to two that is with space for seven The buffer space was seven It went down to six when we received this frame But when we send the act it means we've removed it from the buffer again. So it's back to seven We have seven spaces in the buffer That is the blue rectangle is seven frames long But then shortly later we receive three more frames Four five and six They're putting the buffer With a note here the buffer has space for four frames Seven through to two the window We'll continue in a moment the the destination, but let's come back to the source the sender We had sent four frames three four five and six have been sent But then I receive an act saying the receiver is ready for frame number four Well, if it's ready for four I have already sent three four five and six What that tells me is that three is done That's finished four five and six are still being processed Maybe they are still in the queue to be processed by the destination system. So Four five and six are still outstanding when I receive this act And I'm allowed to send four more essentially this rr4 Acknowledges frame f3 It says f3 is done Every frame that's acknowledged allows us to send one more That is the window opens on the right-hand side That's a detailed example. Let's see if you understand it by letting you finish the case In a couple of steps What first Let's say at this point in time Source aid now has five more frames to send Five new data frames to send What does it do? Think about what will it send? across draw that And after it does that how does it status change? Draw this picture again Okay, so what does it do if it has five frames to send? Anyone want to get it started? Ah, I'll volunteer at the back What's he going to do the source a I've got yeah, I've got five frames. So at the end point for a's perspective I've got five new frames. I want to send. What will I do? Can I send them From a to b I want to send five frames We're not going to wait for an act to come back. Let's send them. Well, if we are allowed to let's send them That's the question. Do we send five? Do we send less than five? That's a good question Look at the blue window The question is then do we need to wait for an act to come back? We don't need to wait That's the key part. That's the difference between this and stop and wait We don't want to have to wait for an act to come back How do I know I don't need to wait? Look at the blue window From the sender's perspective the blue window tells me at this point in time How many more frames am I allowed to send? I want to send five All right, I want to send five But the window says the rules of the protocol tell me I'm only allowed to send four Let's send them We want to send the frames as fast as possible And we need to follow the rules of course and the rules here are no more than four So we don't need to wait for an act for previous ones. We hope that act for the previous ones will come later This is The way to improve the efficiency don't wait for an act always send the new data first Maybe the act will come and we'll see if it does So in fact we can send four of those five frames So we'll send those four frames and of course we do everything in order We were allowed to send frames with sequence number zero one and two Let's send them so f this will be seven zero one two seven zero one and two We're not worried about the act yet We cannot send five because the window only allows four What's the new status maybe hard to draw but The status from The perspective of the source after sending those four frames. It's still got one to send Three has was completed before So we'll draw our vertical bar here three's done four Five and six are still outstanding. I've sent them But not yet received an act And same with seven through to two. I've sent them now as well So four five six seven zero one and two are outstanding How many more am I allowed to send? I've sent seven outstanding. How many more am I allowed to send? No, keep guessing No zero The maximum i'm allowed to send is seven. I've sent the maximum at this stage So we say the window is closed Maybe i'll draw that as That blue rectangle is here It doesn't cover any frames We can think There are seven being transmitted None of those seven have been act just yet So i'm not allowed to send any more The window that tells us how many am I allowed to send it's closed It's a window size of zero So that's from the source's perspective now The source still has one frame to send it cannot do anything with that frame yet So this is where flow control is taking effect The source cannot send the next frame until it gets an act from the The destination b So let's consider a case where b replies What Let's say that b Again, when do we send an act? It varies Sometimes immediately after receiving a data frame Sometimes we'll wait a bit and see if we receive other data frames before we send the act So here i'll say that all right We decided at this point in time we finished This is the destination we finished processing four five and six And when we finished processing those we can send an act and in this specific case I'll say we'll send one act to acknowledge the reception of those And four frames three frames Why do I draw an arrow that crosses over? remember that that The arrows and that the space they occupy is indicating the time it takes to transmit and propagate Maybe it's changed or it's large in one direction. So We've we've seen some frames from a to b in the meantime The acknowledgement has been coming back And it arrives slightly later first This acknowledgement rr receiver is ready for what? What's the number that we include in this acknowledgement? Write it down on your piece of paper I'll come and have a look what is when B sends that receiver ready. What is it ready to receive? We received four five and six And then note that Time is increasing as we go down at this point. We haven't yet received seven zero one or two Before we receive them We finished processing four five and six and send back a response saying i'm ready to receive Seven I've just finished up until six. I'm ready to receive seven I will not draw the status here Take too much space. We'll just focus on the source system When the source receives that act, how does its status change? When the source receives this acknowledgement saying that b is ready for seven I know i've transmitted four through to two If b is ready for seven it means four five and six are finished So our green bar moves here Seven zero one and two are still outstanding I've sent them Not yet act How many more am I allowed to send? Three Four outstanding total should be seven. I'm allowed to send three more If you notice that from the the bar the green bar here to the right edge of the the window It's always seven if you look at all of these pictures four outstanding Three allowed to send We should send that one leftover frame leftover that is Remember we had five to send we only sent four By receiving this act allows us to send more. So let's send that one that we had left over to finish this frame number three is sent I will not redraw this I think We'll get there eventually So here was the the window was performing the flow control We had five to send the window said you're only allowed to send four. So we were only sent four of those five We were only allowed to send that last one that leftover frame once we got an act back In stop and wait We can only send the next frame We can send one frame then wait for an act Here we can send a window size of frames Before we have to wait for an act And that can lead to better efficiency This is a three Three gets sent and let's to finish this say B processes all frames What have we got outstanding? We we've received seven oh one two and three We we process them all by this time So we've eventually finished them so we can send back one last act Receiver is ready for what? We've done seven zero one two and three. I'm now ready for four Our sequence is getting long before seven zero one and two are outstanding And three in fact I hadn't draw with three outstanding We receive an act saying everything up until but not including four is done So All of these are done There's nothing outstanding. There's no other frames off scent that haven't been act so my window Grows to seven I'm allowed to send seven more frames Frames from zero through to them note. We had a wrap around here up to this three are done I've sent them and they've been acknowledged I'm allowed to send seven more frames right if I have more data to send then I would move on And if you looked at the status of the destination B would look the same From B's perspective it has received an act everything up until three And it's got buffer space for another seven frames. So in fact the picture here would look the same at B They should follow each other, but not at exactly the same time So a lot of new details here in this protocol Let's go up to the top and just summarize what we've gone through In this example, we had a three bit sequence number So we wrapped around after we got to seven in the sequence numbers The destination has a buffer space for seven frames Stop and wait you only need buffer space for one frame. So here we have More requirements on the memory for the receiver and also on the the source We saw some different cases here. We sent three frames We can acknowledge multiple frames by just sending one act And the way that we Indicate what's acknowledged we say what's the next number We don't say what was done. We say what do we want next? We don't always have to wait for three frames before we send an act It would differ on different scenarios in an exam or quiz question. I would usually tell you For example, I would say assume every frame we send an act Assume every second frame we send an act just to make it easier But in a real implementation, it would vary on different factors And we saw that the window closed at that last point Sorry here. We got to a point where A has frames to send But is not allowed to send any because they hasn't received acts for the previous seven Yet the window was closed As we receive acts we can send more as we transmit data we can send less That is the window gets smaller I'll give you some quiz questions that will allow you to practice the calculations of the the the window size The next frame transmitted and so on so you can Look at further examples of that that sliding window flow control Before we summarize on the performance any questions on on that example You had quest many questions before It's all solved Good It's very complex and it's very hard to capture in the one hour that we have so You may need to go back and look at it And especially when the quizzes open have a look at the quiz questions. They'll be smaller But we'll test the same concepts of okay if we transmit these frames What's the window size after doing that? So test those concepts so you can get some practice Much more complex than stop and wait needs more memory than stop and wait But an advantage of sliding window can be we can be more efficient than stop and wait And let's have a look at that to illustrate that concept with An example which you have a few few pages forward on your handouts Where is it the example we want to look at if you slide forward Is this one you have this printed out, but it's maybe the green doesn't come out so well This is sliding window flow control But here we'd like to know well, how well can we perform? What's the best efficiency we can achieve in the previous example? Sometimes we had no data to send The best efficiency can be achieved when we've always got data to send So this is a case with sliding window flow control The numbers were given to make it easy to calculate propagation Transmission act transmission of 10 The first case is a two-bit sequence number 0123 0123 and so on and a maximum window size of three and the The boxes on the left indicate the frames that have been Transmitted or an act they'll be gray as we see in a moment Green means we're allowed to transmit so in our previous example the green boxes are equivalent to the blue window Red means we've sent them, but we haven't yet got an act And anything to the right of the green or the white boxes. We're not allowed to send yet So I think the green is equivalent to the window in the previous example in this example Originally, we're allowed to send three Windows three So we transmit those three we transmit frame with sequence number zero Then one then two we're allowed to send three. So let's send them Transmit frame zero Means we're allowed to send two more we've sent one allowed to send two more two green ones transmit frame one We've sent two zero and one we're allowed to send one more Frame two when we transmit frame two There are three outstanding We're not allowed to send anymore so The red ones are those which are send but not yet act Because our maximum window size is three We get to transmit zero one and two Then we must wait The window was three you cannot send anymore until you get an act And in this particular case, we get an act at about or at exactly five hundred and ten We'll not calculate the numbers. We've looked at that previously When we get an act In this case, there's an act for every data frame Think receiving an act allows you to send one more So I'm not allowed to send any but then I receive an act. Oh good. I can send one more So we transmit frame with sequence number three And we're back to three frames transmitted outstanding have to wait for the act next act The next act arrives at times six hundred and ten Good. I'm allowed to send one more frame zero. I transmit frame zero And turns out when that's finished I receive the next act Allowing me to transmit frame one after transmitting three zero and one I'm not allowed to transmit any more I have to wait for an act When does the act come at a thousand and twenty? And you see the same pattern arrives if we get to transmit three and then wait for an act Transmit three wait for an act Assuming we always have data to send You can check the timing there that that's actually to scale in this case What's the efficiency in this case? That's what we care about how How efficient are we in the data transfer? Well The source gets to send three frames And then wait for an act and if you look at the timing it's really sending three frames every five hundred and ten time units If you follow that picture you'll see five hundred and ten we send three then wait for an act Then it repeats Send three wait for an act every five hundred and ten time units three frames In the question if you go back to the top it says that every data frame 90 percent is payload 10 percent is header So three frames every five hundred and ten time units So of those three frames 90 percent is payload and throughput is an indicator Or efficiency is considering payload only so we get an efficiency of about 53 percent Three times 90 divided by five hundred and ten or in other words Every five hundred and ten time units we spend 270 time units sending payload three by 90 There were no Units given in in this case. It's just general We get about 53 percent with a window size of three If we increase the window size the efficiency changes Exactly the same scenario, but a three bit sequence number and a window size of seven We're allowed to send seven frames So we're going to transmit seven that is zero through to six And you'll see as we transmit frames the window gets smaller the green boxes get smaller But note something different that happens here We're allowed to send zero through to six While we're while we're transmitting I think or when we just finished frame four We actually receive an act for one of the first we sent We get an act back while we're transmitting that first window of frames Every act indicates we can send one more So if you follow it through if you look at the green boxes In the window never closes We're always allowed to send more than one frame or more than zero frames The green boxes if we keep following it through It's never closed The consequence is we're always sending If we're always sending we achieve the maximum efficiency at the best case we can do And if you keep going we'll always send frames or always receive frames The only overhead is header We get an efficiency of 90% in this example 100% of the time sending frames 100% of the time receiving frames 90% of the time receiving payload 10% of the time receiving header So we say 90% efficient in this case So here with sliding window we can achieve the the maximum possible efficiency It depends simply on the the payload to header ratio You'll see some quiz questions will ask in such a case What efficiency you can get or to compare two cases What window size do we need to achieve the maximum efficiency? Three got us 53% Seven gets a 90% Can we use less than seven to get 90% Maybe six maybe five or other numbers So you'll see some questions about that