 We went through an example of sliding window flow control to illustrate some of the features of this protocol That is we were allowed to send more than one frame before we have to wait for an act a window size of frames And that's actually a parameter in the protocol. So under different conditions, you'll set the maximum window to different values maybe the The technology or the link that uses a sliding window flow control would define the value of that parameter maximum window size What's a good value? It depends upon the relationship really between the propagation delay and the transmission delay and These two examples which you have printed out Give one scenario where the propagation delay is 200 time units and the data transmission is 100 time units and if you follow through and See with a window size of three how much we're allowed to send with those delays. It turns out we can send three frames zero one and two taking 300 time units and Then with a window size of three, we'll have to wait for the act to come back before we get the next one so The timing in this example turns out such that we send Three frames consuming 300 time units The first act doesn't come back until five hundred and ten and Therefore we need to wait for that act to come back because the window size is limited limits us to sending three frames and The result is we get this process of send three wait for an act send three wait for an act and so on So the efficiency is with delivering three frames per five hundred and ten time units and Just in this particular question to make it more interesting. I Said that the data transmission 90% of the time we send payload the actual data 10% of the time we send header so we really spend Every five hundred and ten time units we spend two hundred and seventy time units transmitting payload We spend three hundred time units transmitting our frame but only 90% of that is payload so 90% of 300 is 270 so we send two hundred and seventy time units sending payload every five hundred and ten time units 270 divided by five hundred and ten is About 53% the efficiency of this protocol Which is at the bottom of that picture in this other case same scenario, but we have a window size of seven So we've changed the parameter of our protocol, but the same link With seven frames. We're allowed to send seven before we have to wait for the act The seventh frame would be frame with sequence number six, but it turns out with the particular propagation delay We're still transmitting the fifth or the actually the sixth frame frame with sequence number five when we get the act back So in this case if we have it at the window of seven frames, we're still transmitting frames in that window While we get the first act back Receiving an act means we can transmit more So in this case, we never have to wait for an act to come back because the window is large enough that we Get the first act before we complete that window That is we get an act saying you can send one more We transmit one more and then we get another act say we can send one more we transmit one more and that continues forever if we keep going The end result a is always sending frames 100% of the time sending frames B spends a hundred percent of the time receiving frames 90% of what it receives is payload 10% is header. Hence, we get an efficiency of 90% That's the best case we can get Given it the payload to header ratio So here we calculate the efficiency efficiency simply from the ratio between payload and header 90% of the frame is payload So this is the best we can achieve if we increase the window up to eight It doesn't get any better. We can't send more if we decrease the window down to six I think if you check with six it still achieves the 90% Because with the window size of six We'd get to transmit frames up until five before we have to wait, but we get the act back So that's okay If the window size was five, I think if you do the calculations, it's slightly lower than 90% We spend 500 time units transmitting Then wait 10 time units before the first act comes back So there's some optimal window size in this case If we know the propagation delay, we know the transmission delay, we can find an optimal window size That gives us the best efficiency Any questions on sliding window flow control? The general operation and the efficiency There is a quiz available today this afternoon and the quiz has about five questions on Stop and wait flow control Sliding window flow control and the next things that we're going to talk about the error control mechanisms And and you'll have to do some calculations like this given a scenario Given the propagation delay and the transmission delay. What's the efficiency we can achieve? So you'll get some practice with that This question is the the colored picture that we have printed there the green and red one that is The data frame of 9,000 bits a thousand bits header 90% payload 10% header and If you do the calculations we get data transmission time of a hundred milliseconds propagation of 200 milliseconds act of 10 milliseconds With either a two bit sequence number or three bit sequence number. So the answer to that is those two pictures We're focused Maybe go back to this one. We're focused on data going in one direction only So here the rules for the protocol are for data going from a to B a maintains window For the sender and be maintains the window for the receiver and they follow the rules to deliver the data But of course in many applications, we'd like to send data back in the opposite direction Okay, that is B would like to send data to to A So the general approach is you treat the different directions Independently that is you use sliding window flow control to send from A to B and for data coming from B to A you use a different or an Independent implementation of sliding window flow control to send it back. That is you use a different set of variables for sending in the opposite direction There's no relationship between the data going in both directions and the windows But there's one exception and the exception is commonly used in protocols. It's called piggybacking we note here that be received three data frames and sends back an act an Acknowledgement contains no data in this case the receive ready message is just a short message saying I'm ready to receive frame with sequence number three It's a short message. No data included but if B also wants to send data back to a then piggybacking as the approaches instead of sending two messages the act Acknowledging the previous frames and a second message with data going from B to A Combine them into one message create one message which contains data and Inside the header of that data you indicate also that this is an act and The next frame expected is three act. So usually you think of an acknowledgement is just header a Data frame is header plus payload We can combine the two Create one frame with the payload and the header fields which serve the purpose of the header for the data Plus the header for the act So that Saves on transmitting Some bits across the link so that concept of combining data In one direction where the act in that same direction is called piggybacking we piggyback The data on top of the act or the other way around the act on top of the data I think we're not saying any more about that. We may see some examples in later systems, but I Just be aware that we can Improve the transmission in both directions by combining a data and act frame I Think towards the end of the course. We may see examples of piggybacking Everything up until now has been about flow control We don't want the sender to send too fast to overflow the receiver and When we've analyzed flow control we assume that there are no errors on the link Everything that was sent was received So that was our assumption so far let's exchange that and let's consider what if we send something and What sent is not received we have an error on the link our frame is lost Or we send something and the frame received has bit errors inside and the receiver cannot correct them So what happens when we have errors? Turns out we can use similar protocols to provide retransmissions of frames If you remember back to before the mid-term we talked about error detection with parity bit We can send a frame and the receiver can sometimes detect if there are errors inside that frame And we also said we have forward error correction We can send a frame specially encoded such that in some cases the receiver can correct the errors But in some cases they couldn't correct the errors There were certain cases where it's it's not perfect So we still need some way to ask the sender to retransmit to send again and that's what we'll see here So we need a way to detect and correct errors For example we send a frame and Because of errors it doesn't get to the destination We say that's a lost frame Why maybe there's a lot of errors on the link or maybe that the There's actually a device in between the sender and receiver and that device fails for some period of time So the frame doesn't get there We may also send frames and they arrive at the destination But they have so many errors in there that we cannot use that data. So we'd call that a damaged frame Lost and damaged frames lost not received damage received but with errors How do we deal with them? Well, we have error detection and forward error correction, which we've discussed previously But they're not perfect. So the other mechanisms we use we use acknowledgments We send a frame to the destination and the destination sends back an act saying thank you that frame is correct No problems with that frame. That's a positive acknowledgement. I've received the frames with no errors That's one approach. We'll see We may have a negative acknowledgement Send a frame to the destination the destination Destination sends back a message. Sorry that frame you send me has errors That's an acknowledgement that something's gone wrong. And if we detect something's gone wrong We need retransmissions. We send a frame. We get some message back indicating that The frame wasn't delivered or had errors. So we retransmit that same frame With the hope that the second time we send it there are no errors and it's received correctly When we combine that with a positive acknowledgement, we'll need a timeout mechanism. The approach will be I Send a frame to the destination. I Wait for a positive acknowledgement If the destination receives that frame it sends back a positive acknowledgement saying thank you everything's okay And then I move on But what if I send the frame and there's an error and the destination doesn't receive the frame? If it doesn't receive the frame, it's not going to send a positive acknowledgement and If I'm waiting for a positive acknowledgement, I'll wait forever So we'll implement a timeout mechanism. I send my frame I wait for some time if I don't receive the act within that time then I'll assume it's lost and Resent retransmit So we'll see that in play in three different implementations of Protocols they're called automatic repeat request or ARQ for short and and The three ones we'll look at the three general ones are called stop and wait ARQ Go back in and selective reject ARQ and it turns out that the mechanisms are almost the same as Stop and wait flow control and sliding window flow control They will see the very similar That is stop and wait ARQ is built upon the mechanisms of stop and wait flow control and The last two go back in and selective reject user sliding window type approach So let's go through them. We'll spend a bit more time on stop and wait and the last two will just summarize The stop and wait ARQ protocol is based on the flow control equivalent The source sends a single frame. Remember stop and wait flow control send one frame Wait for the date act send the next frame wait for the act and so on Here the source sends a single frame But we now introduce a timer So you can think I send my frame and then I start my stopwatch and I start counting time and I'm waiting for an act to come back If an act is come comes back Then I stop my timer and I can move on to the next frame. That's the normal case. No errors I send my data it gets there to the destination the destination sends an act back. I Can move on to the next frame? What if no act comes back? For example, I send my frame. There's an error B does not send back a positive acknowledgement Well, the timer is used here if my we say the timer expires eventually we have a time out So we'd have a parameter that says wait for an act to come back up to a maximum of x seconds and If we reach that time Then and we haven't got the act then we'll retransmit We'll send a copy of that frame that we just sent What does the destination do? if the destination receives a Data frame it contains no errors It's error-free Then the destination can send an act If the destination receives a frame which contains errors It's what we call damaged then it discards that frame It's as if it didn't receive it and No act will be sent our frames will include sequence numbers We'll see why in a moment, but we need at least we need a one bit sequence number in our frames with one bit sequence numbers The frames will go zero one zero one zero one So let's see it in in operation Just an example of the normal case in this case. There are no errors. So it's easy and it looks just like stop-on-rate flow control For example a has some data to send at this time. It transmits a data frame Know that there's a sequence number in the header The first one will label zero Transmits the data frame when B receives that data frame it processes Once it's finished processing. I say the data is delivered and When the data is delivered, we've finished processing we can send back an act saying a positive acknowledgment saying thank you That data was successfully received and As we saw with sliding window we use the concept of an Acknowledgement number saying thank you the next one I expect is one So the data had sequence number zero The act has an acknowledgement numbers of one because the next sequence number expected is one We don't say thank you I just received data zero I say thank you I now expect data one We send that act back Because it's stop-and-wait a Transmitted the first data frame even if it has more data to send it's not allowed to send until it gets the act back It receives the act here, so it transmits the second data frame data to the sequence number is one It arrives. Maybe there's some processing Alright, so the processing is not instantaneous. It may take some time Once we're finished processing we send back an act With the one bit sequence number. I just received data with sequence number one what number comes after one What number comes after one? not to Zero comes after one when we only have one bit to count zero one zero one zero one okay when we have a counter in a computer We we don't we can't go up to infinity Because when we store that value we don't we have a certain number of bits So here we just have one bit to store that value. We can only go up to one and we wrap back to zero so Data with sequence number one was received The next one I expect is zero So I send back an act acknowledgement number zero We already had the third piece of data ready to send so now we can transmit it and Then an act will come back so you'll see data act data act data act and so on and The sequence numbers are alternating zero one zero one if you look at the data Zero one zero one and so on so that's a simple case. There were no errors. I Want you to try and draw a diagram of the same scenario where the first data frame is successfully delivered But the second data frame has an error in it and doesn't get to live it to be so try and draw that basically this diagram where This one's the same. That's easy. This data frame doesn't get to be It's lost for some error in the link. It doesn't arrive. Then what happens? The timing doesn't matter so much. I mean we're not giving the exact scale of the timing just to show that the first one will be successful the second one something will go wrong and then see what would happen according to the rules of stop-and-wait ARQ Draw this but where the second data frame is lost So the first data frame will look exactly the same as the previous picture. That's the easy case and I will not draw the processing time. That's assumed that as soon as we get it. We send back an act So this is our first data frame. So we'll say data sequence number zero This will be act with act number one Thank you for data zero. I now expect one to come back and To keep track that we remember this is the first piece of data and At this point in time the first piece of data is delivered to the destination user or application So a has the first piece of data number one and it's delivered at this point in time Then a has some more data to send so let's send it and the the next piece of data We include sequence number one in the header note that this is the second different piece of data data to and What happens let's assume that we transmit it and there's an error It doesn't get to be in this case the frame is lost for example What happens next? There's some problem on our link We transmitted the frame, but there is an error in the link and it doesn't get to be What does be do? What does be do? nothing B does nothing why because B has Received nothing assuming B's got no data to send B's just the receiver. It received an act It received a sorry it received data and send an act and that's all B is going to do receive data send an act It sent the act the previous one and B is waiting for data waiting waiting waiting B is not going to do anything because it's not going to receive this data. We said it's lost It doesn't get to be B doesn't know it's lost B is at the other end point B doesn't know that a centered Because it wasn't Received So B does nothing. What does a do? How does a know that this data is lost? I? Transmitted the frame think Maybe a simple case the link actually has two segments from my laptop Connects in to say a switch a small intermediate device Which then connects by another cable to the destination computer B my laptops a the switch is just some intermediate device That allows me to go a bit further and then destination B Let's say I sent a frame to the switch the switch failed for a short period of time. There was an error And the frame disappeared. It doesn't get sent to the B So how do I know that? How do I know my frame was lost I don't receive an act How long will I wait for an act? I could wait forever But then I would never get to send anything so we need a timeout interval So we need another parameter that says that Right if we wait for too long Let's give up waiting and try again So the way that would be implemented we think that After transmitting the frame we would have done it here as well Maybe we even draw that after transmitting the frame say we start a timer and In this case we start the timer and If we receive an act back before the timer reaches its maximum value We say a timeout occurs then that's okay We can move on but in this case we'll start the timer and There'll be a maximum value and let's say it's at this point The timer expires or sometimes we say a timeout occurs depends upon the value. Let's say the timeout period may be 500 milliseconds So I transmit my data. I wait. I'm waiting if I wait for 500 milliseconds then I say Timeout occurs a timer expires We'll have an upper limit there and that allows Well, that's when a assumes that something's gone wrong I've waited enough time for this data to get to be and Enough time for B to send an act back, but I haven't received an act That suggests that there's an error So when the timer expires then we retransmit the timer expires So we realize I'm most likely not going to get the act Something's gone wrong. So let's try again let's send a data frame and It's a retransmission of the previous one. This was the second piece of data We actually send that second piece of data again and the sequence number It's the same as the previous one. It's still sequence number one Let's say in this case it was successful The data does arrive. There wasn't an error. Our device is working correctly again the data arrives B Receives a data frame and receives the second piece of data and can send back an act and the act Says thank you. I just received one. I now expect zero The next number in the sequence and of course we would have started our timer in this case as well We send the data. We start the timer But it doesn't reach the maximum. We get the act first There are two events that can happen at a after I send data Receive the act or timer expires Whichever happens first triggers what we do next in this case We receive the act before the time out before the timer expires Receiving the act means we've been successful. We can move on to data three The next data has sequence number zero and It's the third piece of data So the green numbers indicate that this is different data and we can Send the data get an act and continue will not draw anymore Any questions so far on the retransmission of stop-and-wait ARQ we now need a timer and If our timer reaches a maximum predefined value retransmit, okay Also hard this one Consider the second case what happens so consider the same again a third time But the acknowledgment is lost the act further So consider the case where first one successful Data gets to be B sends an act back and the acknowledgment is lost We just covered lost data Now draw the scenario when there's a lost act The second act that comes back is lost So just repeating Same as the first case data one successful or data with sequence number zero is successful Data with sequence number one is transmitted it gets to be sends back an act that act doesn't get back See what happens? This is data zero This is act saying thank you. I now expect sequence number one and this was our first piece of data and at this point in time B has received data one and when I note here The protocol at B receives data one has processed it and think it passes it on to the application of computer B Or the user that's sitting at the computer. They use it now this Moving on to the second piece of data transmit It gets there okay this time We send an act and that we have an error So this is the second piece of data data Sequence number one We would have had the timer here. Maybe we can draw that it didn't expire. That is the time we started the timer But we got the act back before it expired so we can stop the timer and move on here We'll do the same. We'll start the timer B receives data Processes and passes at that time that data on to the user Then we send back an act Sequence number zero. I just received one the next in our sequence is zero But we have an error The act is lost. We may lose frames in either direction. What happens next? Complete the diagram continue and see what happens next what's What's a or B going to do in the next step? What's a going to do? Why will it send data again and how does a know the act is lost? The time out okay, so the timer is going to expire Because we get the act back. We'll never get the act back. It's not coming so from a's perspective I've sent data and The acts not coming back so we know that eventually the timer will expire After some time will have a time out and then see what happens after that We time out that triggers a retransmission. We send again Data we use the same sequence number because it's the same Data it's the second piece of data and let's assume it gets there this time no problems What happens next? What does be do when it gets the data again? Decline or Ignore the correct be gets the data and Realizes This data is the same as one I received before it's already received the second frame How does it know it's already received it? How does Right, how does be know that this piece of data received is in fact the same as the previous one It could look at the bits okay, but how do we know that the bits? Even if they're the same whether it's two pieces of data Which are the same or one piece of data, which is repeated we can't tell the only way to know That this piece of data received now is the same as the previous one is because it has the same sequence number Be previously received data with sequence number one I'm expecting zero if I receive data with sequence number one I Ignore that data I Don't pass it to the application or user. I don't use that data again So we'll say we ignore that But we still send an act the act says I'm still expecting sequence number zero the previous data we receive with sequence number One we've received it. I'm expecting the next one. I'm going to Process and use will be data with sequence number zero When a receives this act it knows that that data was successful and it can move on It can move on to the third piece So importantly here with the last act Be the receiver of the data ignores the retransmitted data because it's received a copy already If we process that receive that second copy that would be a problem Imagine the data was a message going to the bank from some ATM to the main office saying Increase Steve's account by 10,000 baht. That was the data message the bank gets it here and Increases my account by 10,000 baht But the ATM didn't get an act back So it repeats that message and sends it again If the bank office didn't ignore it, then it would have increased my account again To a total of 20,000 baht. So that's the problem of processing that second data We should ignore it, but we still send an act back saying I've got it already Move on to the next one and that allows a to move on to data frame three So two cases there are lost Lost data in the first case and lost acknowledgement damaged frames are similar Essentially a damaged frame. I receive it, but it has errors is equivalent to a lost frame Just ignore the damaged frame discarded a Timer on B side, where would you want a timer on B side? Right, right right here. So the suggestion is we receive data and We If we have a timer here, we don't receive data the next data in some time then that indicates something's wrong Now the problem with that approach is that sometimes a may not have data to send Okay, so in our case a is always sending data to B, but sometimes a has data to send then it stops for five minutes So having a timer in that case will not work because B will not be able to distinguish Did I not receive data because something went wrong or did I not receive data because a's got nothing to send me So B can't keep track of that because it cannot distinguish that case A is the only one that knows whether it's got something to send So that's where we use the timer Any other questions on stop-on-wait? ARQ Yeah, what does the dot mean the dot means at that point in time? Just to highlight here, right the dots not significant. All right, but I mean at this point in time We've received the data I've looked at the data processed it and the contents is passed on to the user Ignore the dot if you like So now really we've extended the stop-on-wait flow control to also handle if we have errors So we can use use this protocol to do flow control and error control provides both features and The reason we use a sequence number if you go back to stop-on-wait Flow control there was no sequence number. There wasn't one needed here. We must have a sequence number for this case for B to distinguish That this data received is in fact the same as the previous one If there was no sequence number, there will be no way for B to know is this a retransmission or is this Just the same data sent Two times So we need a sequence number to distinguish between retransmissions How long should the time out be? Long should the time out be how long should the time out be how long should the time out be? How long should the time out be how long should the time out be? I'm asking you a question sending you a message. I'm waiting for an answer. He's not asked answering fast enough, so I resend I Waited a little bit. I waited for half a second, but he didn't answer so I retransmitted Didn't work so well. I kept retransmitting not giving him enough time to answer The time out the time that you wait before you retransmit should be long enough Such that they've got time to respond If it's too short, we'll keep retransmitting which will be a waste Maybe he knew the answer. He was about to tell me but had no time to in our protocol Really the time out should be long enough such that the data gets to be B has time to process that data Has time to transmit an act and that act can propagate back So the time out should be maybe usually in practice slightly larger than the typical time It takes to get the data there and get an act back. It was less Then we'll always read retransmit So it should be larger than the time to get an act back Now in practice, that's hard to know How long does it take computer B to process a message? He doesn't know that so usually we make the time out slightly larger than what we'd predict it to be or the typical case But what if the time out is very large? What if I ask your question You don't know the answer and I wait for two days for your answer Then that's a very much a waste of my time very inefficient if the time out interval is too large and We lose data coming back to the first one if this time out interval is very very long We transmit the data is lost We're waiting for an act to come back if we wait for a long time Then it's a long time spent not doing anything and that's inefficient so the time out interval should be long enough to allow be to reply and Not too long such that we wait a long time in the case of an error So there's no best one answer But it should be at least longer than the time it takes to get a response And it's usually slept slightly larger depending upon the conditions in case for example the processing time increases but not too long and In fact in different protocols they may have ways to estimate and change the time out interval In say an exam question or a quiz question I may say assume the timeout interval is 20 milliseconds Then calculate what happens So that's stop-on-wait ARQ just jumping back It used positive acknowledgments and retransmissions after timeouts It was based upon the stop-on-wait flow control mechanism the next two approaches are Based upon the sliding window flow control mechanism and you understand that that's more complex We will not go through them in too much detail, but we'll just Introduce the concepts First one is called go back in With sliding window flow control. We're allowed to send multiple frames before we have to wait for an act so the source can send a window size of frames and With error control maybe one of those frames in the window is lost or it arrives in error So if there's no error, it behaves the same as sliding window if there is an error detected by the destination then we'll have a negative act or Sometimes called a rejection or reject message if data goes to be be realizes. There's an error Then it can send back a special act saying this frame was Received incorrectly or there's an error this frame is missing. Please retransmit that frame So we use a negative act here How does the destination know there's an error? Well, if we send a window size of frames like frame zero one two and three and The destination receives zero two and three It realizes one is missing Sequence number one is missing and that detects an error Let's let's look at the example and then we'll see the description of the different techniques Examples here. It's quite small See if I have it here So here we have a window. I think the window size was a maximum window size of seven and the in this example B is going to send an act or receive ready message for every two Data frames it receives in the normal case So what I'll do is at B. I'll just keep track of the frames. It's successfully received and the frame sent by a So a sends frame zero so we say zero is sent and here zero is received Okay, that's fine and Let's say frame one is also sent zero one and At this point in time B receives frame one So it's received zero one and it sends back an act. So this is a normal case Saying I'm ready to receive frame number two And so this is sliding window flow control Nothing's different at the moment frame two is sent Zero one and two are sent frame two is received and Then frame three will get to an error in a moment. This is what's sent and this is what's received So this is the normal case and we send back an act. I'm ready to receive frame four And in fact when a receives is our two. I'm ready to receive frame two. It really acknowledges the first two frames That is a has sent zero one two and three and it knows B has received zero one because the receive ready to means that it knows that B has dealt with everything before to zero one What happens next here? We send zero one and we've sent four Zero and one are done. In fact, we've got an act for them for Doesn't arrive at the destination B. There's an error here. So here's our first error occur So at this point in time We've actually sent an act for Indicating everything up until four is done. So we should have drawn that here Zero and one are done. That is I've I've acknowledged zero one I've acknowledged zero one and now I've acknowledged also two and three Received to I receive three. I'm now ready to receive four Two and three are done as well. What happens next? here We receive this act and Transmit frame five Which frames are done from a's perspective after receiving that act? Zero and one were done before when we receive the receive ready for it means two and three are also done Everything up until but not including four zero to three. I'll just underline them to indicate, right? We're finished with them What happens next? In fact, we're going to transmit frame six We'll just keep track of that Zero and one are done two and three are still done four Five and six are outstanding from a's perspective. They've been sent. We haven't yet got an act for four five or six What happens it be? We've received zero one two and three with act them already that done I'm waiting. I'm waiting. I'm waiting. I receive more data. I receive frame five This indicates to be there's an error I've in the past received an act zero one two and three and now I receive five what happened to four So be realizes that four is missing because it should receive the data in order and That indicates that there's an error and we send this special negative act or a reject message zero one two and three are still done We receive five Because five is received out of order We discard it we throw it away and We send back a special reject message saying I'm still expecting frame number four to tell a Maybe frame four has been lost So Importantly we'll see compared to the next approach here when we receive a frame out of order We've got zero one two and three We haven't got four then we receive five. We discard those frames out of order. We throw away frame five And in the next step, we'll throw away frame six as well Why do we throw them away? Because it makes it simpler for the receiver. We don't need buffer space to store them We don't need to keep track of them and in In some communication devices, we need to have a very low complexity and low memory requirement transmitter and receiver So saving some buffer space saving some memory is a goal in some cases So here we discard five and six We send back that reject message So even at this point What we've received is zero one two and three and They've been successfully act What happens when we receive the reject message? a has transmitted zero through to six Four five and six have not yet been act But then it sends receives a special message saying B is still expecting four and the reject indicates something before has gone wrong Now what a does in that case is assumes four is lost and Goes back and retransmits Everything that it is currently outstanding The outstanding frames are four five and six So it goes back and retransmits those four those three frames four five and six and the name go back in Go back and retransmit n frames Where the n frames are those outstanding? So you see Something's gone wrong. I need to retransmit four plus those which are Have been since have been transmitted since four so I go back and resend for Resend five and resend six we do here Well, we'll see what happens at B We resend for a retransmission We receive four okay this time and in fact we send an act Zero one and two and three are done and sending acts saying I'm ready for five. So four is now done then we receive five and six and At the bottom we're going to send receive ready seven indicating all of those frames are done Yeah up until four So that's the main feature of go back in When you when the receiver detects an error Because it receives frames out of order it sends a reject message or a negative act saying something's gone wrong Please retransmit everything since that frame any questions so far on go back in Four five and six would retransmit it should five and six have been retransmitted It seems a bit of a waste to send five and six because we've previously sent five and six and they actually got to be But to keep things simple at B B discarded them because they're out of order. So the next approach will see is Can be more efficient. We won't retransmit five and six. We just retransmit four But to do that It's more complex at the receiver in that we need to have some buffer space to store five and six We'll see that's the alternative selective reject here. We keep it simple by just re-send everything since four The rest of this picture covers another case of an error I think we'll know it's not spend much time on the rest part, but It covers the case when an act is lost receive ready. I Will not keep drawing the numbers on there Or maybe we can let's see what happens To complete this one Zero one two three four five six have been sent Here we receive a receive ready for five. So we say Five and six have been sent six was sent receive ready five So zero up to four are done at this point in time We transmit seven We've act up until four We're still waiting for an act for five and In fact, although it's not shown in the other parts of the diagram similar to stop and wait ARQ we start a timer after transmitting data so When we transmitted frame five we started a timer Because we will still Expect to get an act back back eventually I've sent frame five if I don't get an act for frame five that indicates an error And that's what this case is showing I've sent five six seven in fact also zero here only up until four have been act and Since sending frame five my timer expires A timeout occurs we say that is I've waited long enough for a frame For an act for frame five I've waited too long. So maybe something's gone wrong. Well, what did go wrong? This act was lost So here's a special scenario when the act is lost We send a special message saying please retransmit the act Okay, so this are a message With his P bit. Don't worry about the P bit. It's a specific implementation. The meaning of this is saying please send me an act Probably one was lost before Why do I send that? I've waited too long for an act for frame five. I got an act saying four was done But I haven't got any since then All right, so let's ask be to send me an act again, and there's a special type of message to do that Essentially requesting an act and where'd my picture go? Sorry, I don't have it on the screen. We send that request for an act and then We send an act acknowledging everything that's been received. Let's finish it on here 017 is received We've act up until six zeros received the next zero that the ninth frame and What are we where am I gonna fit it? What happens at the end I have to go back to here when B receives this Request for an act it sends an act look at the act number one It's saying everything up until one is done It's received five Six seven zero. I'm now expecting one so this Last act in the sequence says to a everything up until one is done So we can now move on and it will send frame one and frame two You can finish off writing the numbers on your picture. I've run out of space But it was a special case with the lost act Maybe the main thing to focus on then go back and is the lost data and how it realizes that and Goes back and retransmits all frames since that lost one so When when they send this request for an act B sends back an act saying all right. I've done Everything up until zero so now I expect one and then allows us to move on So two mechanisms there We lost a frame B recognizes that loss because it receives a frame out of order It received five before four So it spent us sent a special reject message a second mechanism If we don't get an act within a reasonable amount of time we time out then we can request an act please resend an act and then we can move on Based upon the act number any questions on go back in Selective reject is almost the same But we don't go back and retransmit those four five and six we just go back and retransmit for same scenario zero one two three We can keep track I'll just draw at the receiver be we receive zero Receive one and we acknowledge both of them Saying I'm ready for two. I Receive two I receive three This is selective reject and we acknowledge both of them zero one two and three are done Same as the previous example. I lose or frame four is lost We receive frame five Got one two and three they are done and Five is received and buffered here's the difference between go back in go back in would discard five and send a reject message Because it arrived out of order here Again, we in we realize that there's an error I've received zero to three then I get five Where's foregone? So I'm going to send a special reject message a selective reject That is it means you'll only need to retransmit a selected frame I'm going to send that but in addition I'm going to use some buffer space at B to save frame five for future use We're going to receive frame six we've got five and six in the buffer and a when it receives the selective reject message for four in tells a to retransmit only frame four It doesn't have to retransmit five and six and that's the main difference between selective reject and go back in Go back in retransmit multiple frames normally selective reject retransmit a selected frame we send four and Now what have we got? We've got zero one two three. We slot four into its place We've still got five and six saved and we can send an act Saying everything up until six has been act now Ready to receive seven so that's the key difference we want to illustrate there go back in as simpler It doesn't require so much buffer space and processing at the receiver but is Can be inefficient in that we retransmit frames which weren't even lost So that you've reject can be more efficient in that we only retransmit one frame here not five and six as well But requires some buffer space and processing at receiver Which one's better it would depend upon how many frames we often lose The delays in the links and how complex we can accept and how much memory requirements we can accept on the receiver only the frames which are rejected or timeout are retransmitted subsequent frames are buffered It minimizes retransmission. We don't retransmit as much as go back in that's good But it means we need a buffer at the receiver That's bad and it's more complex at the transmitter. It needs to keep track of what it sent Which is also bad in some cases Turns out that the simpler is more commonly used So selective reject is maybe used only in and some very special cases like satellite links when there's a long delay And it's a lot to retransmit. It's very costly to retransmit and that Complets our study of the three main ARQ protocols stop and wait ARQ Send one data frame get an act back Retransmit the data if we have a timeout and then the two based upon sliding windows selective reject and go back in Where we can detect an error based upon getting frames out of order If I receive frames out of order it indicates something's gone wrong these mechanisms are used in many linked level protocols and also applied for Many other protocols used on the internet today So not just on links, but when I download a file from a web server to my laptop across the internet It will be taking use of some of the mechanisms that we've talked about here So that's why we spend some time on it. We talked about how long should a timeout interval be There's a list of a few examples that use some of those mechanisms