 And the flow control protocols we looked at was stop and wait on sliding windows. So two main mechanisms for flow control. Stop and wait, simple but inefficient in that we send one frame at a time. Sliding window improves upon the efficiency by sending multiple frames before having to wait for an act, an acknowledgement. But it's more complex. We're going to see that the error control mechanisms, the ones that we'll look at, are based upon stop and wait and sliding window. That is, we'll see they're very similar, but they add error control. Well, what is error control? Well, the ability to detect and preferably correct errors. Errors when something goes wrong across our link. We send some data and it either doesn't arrive at the destination. I send a data frame from source to destination, but there's an error on the link such that that data frame doesn't arrive at the destination, it's lost. We say that's a lost frame, no frames received, but I send something. That's an error, because we know that in many applications when we send data, we want to make sure that it's delivered 100% reliably to the destination. Everything we send arrives. Why may data be lost? Well, it may be a characteristic of the link. Not all links and the physical layer protocols we use are not perfect. So we may send some bits and it may be that the receiver cannot receive a signal that represents those bits. That's common in wireless systems. I transmit a data frame from my laptop to the access point, but there's some interference when I transmit it such that the access point doesn't receive or cannot make out that it's received any bits or a frame. So we can talk about frames that don't arrive at the destination. In fact, when we have a link which is made up of repeaters and intermediate components, it may be possible that there's an error on one of those intermediate devices such that, for example, they fail, such that the frame doesn't get to the end point. So we may have lost frames. The other thing may happen is that a frame arrives at the destination, but that frame has some bits in error. Our frame may say, have 1,000 bytes of data. We receive that frame and the receiver can detect that that frame of those 1,000 bytes, maybe several bytes are wrong, bit errors. Send a bit zero, receive and think it's a bit one. We call that a damaged frame. We receive the frame, but we can detect that it's wrong. And we need to fix that case as well. So the techniques we have available, well, really we can break them into two different types of techniques to detect and, importantly, correct errors. There's what's called error detection and FEC forward error correction. Discussed in previous topic. Well, no, we didn't, we skipped that topic, okay? That's one technique for correcting errors. The idea, and we're not going to cover it. The idea is that when we send data, we actually send either some extra information or, in fact, transform that data that we send into something different such that if there's an error at the receiver, the receiver can detect that and even correct it based upon the extra information sent from the source. We're not going to try and discuss that if you want to look and find out how error detection works. Possibly you've seen it in other courses looking at parity checks in computer hardware, one form of error detection. CRC 16, CRC 32 is another error detection algorithm. And there are different forward error correction algorithms. If you want to see some examples on the course website, you can find the lecture notes for that topic. We're not covering it this semester. We're going to cover the other approach, which is maybe one of the, is probably the most used approach. And that is that we send our data and if our receiver doesn't receive that data, then we ask the sender to send again, retransmit. And it has different components or different ways to do it. One is called a positive acknowledgement. Source sends data to destination. If destination receives that data, it sends back an act. A positive acknowledgement saying, thank you, I received that data. So send data, the normal operation, the source sends data to the destination. The destination sends back an act, an acknowledgement. Indicating to the source that the destinations receive the data, that we didn't lose data, that it wasn't a damaged frame. But what if it is? What if the frame is damaged or what if the data doesn't arrive? Well, if in the normal operation we send data and expect an act back, if we don't receive an act after some time period, the source will retransmit. So the idea is from the source's perspective, send some data, expect an act to come back within some time period. If you don't receive that act, then send the data again. And that's a retransmission. So we use positive acknowledgments and we use retransmissions after timeouts. A timeout is some predefined period that the source will wait before retransmitting a data frame. There's another mechanism that's sometimes used called a negative acknowledgement. A positive acknowledgement is the destination saying, data was received successfully, positive. A negative acknowledgement is the destination saying there was an error. Either the data wasn't received or the data was received in error. Which is a negative result. And this should be a similar response from the source, retransmit, send again. So we'll see some examples of these mechanisms when we go through different error control protocols. So error control, fix errors across our link. If something goes wrong, we want to make sure that the data eventually gets delivered to the destination. And the approach we're looking at is using retransmissions. Send the data, if it doesn't get there, send it again. And if it doesn't get there the second time, send again. With the hope that after trying several times, it'll eventually get there. Now there's some special cases to consider what if we try too many times. We'll talk about that as we go through. Using acknowledgments and retransmissions and timeouts. Together, acknowledgments, retransmissions, timeouts, both positive and negative acts. Those mechanisms we classify and call automatic repeat request. So we have requests coming back and we aim to automatically repeat the data when needed. And that's abbreviated or the acronym is ARQ. So we generally talk about ARQ mechanisms. And the three versions of ARQ mechanisms that we'll go through, the three main ones, a stop and wait ARQ, go back end and selective reject. And what we'll see is that stop and wait ARQ is very similar to stop and wait flow control. Send one data frame, get one act back. Data, act, data, act. And the next two, go back end and selective reject, use the concepts of sliding window flow control. We have a window. Send a window of data frames. Get some acts back. Send a window of data frames. But they have extensions upon the flow control mechanisms to indicate if an error has occurred. And that's what we need to go through. Let's start with stop and wait. Very similar to stop and wait flow control. The rules, the source sends a single data frame. And then it starts a timer. You can think the source has a timer. We send the data frame, start a timer. And as with stop and wait flow control, when we send the data frame, we must wait for the act to come back. After sending that data frame, we store a copy of that data frame in the buffer at the source. We just maintain a copy. We're waiting for the act to come back. If the act arrives back within some period of time, we'll stop the timer and move on to the next frame. This is a positive act scheme. Send the data. If we receive an act back, that means that data was successfully received. So the normal case, if there are no errors, data, act, data, act. But what if there's an error? What if I send the data across the link, but for some reason it doesn't arrive at the destination? Well, if the data doesn't arrive at the destination, then the destination is not going to send an act back. So from the source's perspective, it sends the data frame and now waits for the act. It's not going to wait forever. The act is not going to arrive because the data was lost. So the source, when the timer reaches some predefined value, we say when the timer expires or a time out occurs, the source assumes that means the data was lost. And retransmits a copy of the data that it previously sent. Sends it again. There are a few more mechanisms that will go through, but let's illustrate that with a diagram. And I think it's almost the same diagram that we've seen with stop-and-wait flow control. I've made up a scenario where A has three chunks of data to send to B. And as with stop-and-wait flow control, we create a data frame, send it to B. If it arrives, B processes that data, delivers it to the layer above, and sends back an act, a positive act, saying thank you, that was successful. So we get a data and an act. And A, because of the flow control mechanism, could not send the second piece of data until it received the act. It receives the act, sends the second data frame. So this is data frame two, or the frame containing data chunk two. Sends that, B receives, processes, sends back an act saying thank you. Data three, act, and we can keep going. This is for the simple case where there's no losses, no errors. In fact, it looks just like stop-and-wait flow control. The first thing to notice, if you compare it to the stop-and-wait flow control protocol, with stop-and-wait ARQ we include sequence numbers. Our data has a sequence number. We saw with sliding window we needed a sequence number, like zero through to three, zero through to seven. But with stop-and-wait flow control, we didn't have a sequence number. It wasn't needed. But we do need it here. In fact, we need a one-bit sequence number. With one bit, the sequence numbers in decimal are 0, 1, 0, 1, 0, 1. Just alternates. Sometimes called alternating bit protocol. So we see that the first data frame has sequence number 0, I've drawn it in the brackets here. The second data frame has sequence number 1. The third data frame, a new one, has sequence number 0. We'd see 0, 1, 0, 1, 0, 1. Just alternates because we just have a one-bit sequence number. So that's a small difference to stop-and-wait flow control. The acts have what we call an acknowledgement number. And it works similar to the acts in sliding window. And there are act numbers in most protocols. The act number, the acknowledgement number, indicates the next sequence number of data expected. Send data with sequence number 0. B receives that. Successful. Sends back an act with act number 1. With the meaning of, I've received data 0, I now expect data 1. Data with sequence number 1. A sends data with sequence number 1. B receives it. Sends back an act saying, thank you. I've received that data. I now expect data with sequence number 0. So the act number here is 0. So the next one we send is data with sequence number 0. Note that, and this is what some people get confused or miss, the act numbers, in fact I think all of the protocols that we look at, the act numbers indicate the next value expected, not the last value received. I now expect 1. So A sends 1. I now expect 0. A sends 0. Okay, just make note of that. That was the same in sliding window. All right, you're not very interested in this because there are no errors. The reason for stop and wait ARQ is to handle errors. What if something goes wrong? Let's consider a case. Try and draw. What happens if, let's say, the second data frame, this one, doesn't arrive at B. I'll give you a few minutes to try and draw this diagram to stop and wait ARQ, but consider the case that the first one's okay, but the second data frame is lost between A and B. It doesn't arrive at B. What happens? Try and draw that diagram. Frame loss here. We lose data. So the first data frame is successful, so it will look exactly like the first frame here, but the second one doesn't get to B. Then what happens? And I'll try and draw it as you are as well. What happens next? So this is the same. I've just simplified it a little bit. I haven't written data at, but the sequence numbers of our data, our at, what happens if this one doesn't arrive at the destination? It's going to wait, the source is going to wait for some, it's timer to expire. How do we draw that? We're going to say it's sent and let's say it doesn't arrive or across meaning that frame that was sent doesn't get to be the destination. What happens next? Well, note that whenever we send a data frame, we start a timer. So you think we start our stopwatch and we're counting and waiting for an act. The source is waiting for an act to come back. Of course there's never going to be an act because B never receives the data and therefore B will never send an act. So A, the source has a timer and once it reaches some value, some predefined value, we say that timer expires or a timeout occurs and that triggers a retransmission. So I'll say that we have some timer, say it starts at some point and let's bring it down to here. That's indicating some timer or some timeout period. And what happens is the idea is that we transmit our data frame. Now we wait for an act. We're waiting, we're waiting. We expect to receive that act within some reasonable period of time and in fact we'll talk later how we determine this time. But we expect to receive the act. We haven't received the act. We haven't received the act. All right, we've waited long enough. That's this timer expires. We've waited long enough. We assume that something's gone wrong. The data was probably lost. Maybe the act was lost in response. So we assume that an error has occurred and what we do to fix this error is to send our data again. We retransmit. So we'd send the same data frame a second time and the sequence number of that data frame is one again. It's the same data frame. It contains the same piece of data. So the first data frame contains sequence number zero. We got an act back saying I now expect one. Everything's okay. We send the second data frame with sequence number one. It doesn't get to be. A doesn't know what's happened here. Remember these are two computers at the end point of the link. We've waited too long. Our timer expires or our timeout occurs. It means let's try again. Retransmit that same data frame, same sequence number and send it again. And let's assume for simplicity that it arrives this time. So keep drawing the diagram and assume that the retransmitted frame arrives at B. What happens next? Let's say it arrives and it arrives successfully this time. So the source simply sends back the act and let's keep it simple and say the act arrives back and that allows the source to send the next data frame and we can keep going. Let's make note of our numbers. If B receives a data frame with sequence number one the act that comes back has sequence number what? Because we only have a one bit sequence number we're just going to alternate 010101 and the act is the next number expected. So the next data frame will have sequence number zero and I will not draw the act we'll have another act back and so on. So that's just the case where one of the data frames was lost. It didn't arrive at the destination. It also covers the case where the data arrives at destination but is in error. That is, I receive some frame I look at the bits at the destination and I detect that there are a lot of errors in those bits. Something was corrupted along the way. In that case as well the destination may not send back an act. If the data is received in error it's treated the same as if the data wasn't received at all. Don't send an act and eventually the source A would retransmit. There are some variations on that we'll see later. But in this case send the data doesn't arrive wait for a timeout to occur or a timer to expire retransmit. Any questions on stopping wait so far? That's our next case. We'll come to that. That's good. The question is what if this was the case where the data didn't arrive at the destination. What if for example the data arrives but the act on the way back is lost. Let's try or you try. See what happens. On the next slide we just covered the case of data. We lost one data frame. Now I'll try and draw a diagram is if the data arrives but the act doesn't get back to the source. A lost act. This was the case of a lost data frame. The second data frame was lost. Consider the case where maybe the second data frame or it doesn't matter which one. Even the first data frame is received but the first act doesn't make it back. Let's say the first acknowledgment sent by B doesn't arrive back at A. Try and draw that diagram. Need a piece of paper pencil maybe. Your pictures don't have to be as nice as mine but try and capture the main exchange of frames and the events that occur. So the act is sent but doesn't get back to the source A. Let's try and start drawing. What happens next? Again. Alright. Same as before from the sources perspective we've sent data we start our timer so we're waiting for an act we're waiting for an act and eventually our time is going to expire because we're never going to receive the act. The source doesn't know whether the data frame was lost going to be or the act frame was lost coming from B. It doesn't know. It just knows if a timer expires something went wrong and when something goes wrong we resend the data. We retransmit. So yes a timer expires and then resend the data. Now let's add some more information to this diagram which I I didn't show in the last picture but let's go back to see why we got sequence numbers we'll eventually arrive at that. Note that so this is a case no errors. Normal behaviour. Send the first data frame. We had three chunks of data. First data frame contains the first piece of data. It was delivered to the application or the user at computer B. Let's say what is the data? From the protocol's perspective the data can be anything just a sequence of bits. But let's say data one this protocol is used between and between two banks a link between two banks or two branches of a bank and the data is some messages about an account transaction. For example data one you don't have to write this down just to give you an idea of what's going to happen. Let's say data one is increase Steve's account by 10,000 bar. So it's some message from some two computers in a bank indicating what to do with an account. So increase my bank account by 10,000 bar because I deposited money in an ATM for example. So it sends to the central server saying increase that. So that's data one. Data two, data three maybe other messages like increased by 5,000. We won't get to them in a moment. Well let's write them down. They are different messages. Data two is something else like decrease maybe I drew some money after I deposited. Decrease by 2,000 bar and data three is something else. Decrease by 1,000. Just made up examples of data. In fact the data may not be messages like this it could be anything but we'll see why it's important to consider what happens with errors. So in the first case the computer sending these messages is to say some central bank server that records my account total. Data one is delivered and when the data is delivered let's say the application there or the database that stores all this information updates my account balance from originally my balance was zero bar. After receiving the first message my account balance was zero bar. After receiving the second message at this point in time the application here would increase my account balance would decrease my account balance down to 8,000. And then after receiving the third message it would be down to 7,000. That's the normal operation because on one computer it's sending some messages to the central database that keeps my account balance for the three pieces of data. Although it didn't draw it on the previous let's hide this one on this case does it work? That is if we're using this protocol to communicate between the devices does the application still work in the same way? Let's see what happens. The first data message was received here. So data one was received at this point in time and that would decrease my account to 10,000. Data two from the server's perspective was not received until this point in time. The second message is received. Of course that would take my account balance from 10,000 down to 8,000 and then the third message and I don't think I drew it but I think you can work it out the third message arrives here and that decreases my account balance down to 7,000. That is even though we lost some data even though we lost this message between A and B those three pieces of data one, two and three were all delivered to B in order. So we get the same behaviour as if we'd lost no data. So that's the intended behaviour. That's good. Now let's see what happens with the next case when we lose the act. Data one arrives here that is at this point in time B receives the first data message increases my account by 10,000 and balance is now 10,000 baht. The act was sent back B received it, received the data increased my account balance sent back an act saying thank you but there was an error, the act didn't arrive and like we discovered again what the source is going to do is going to time out it's not going to receive the act so eventually it's time it will expire and trigger a retransmission so we're going to retransmit I'm sure you've finished the diagram to see what happens after some time period just draw it to here that's our time out period at that point in time we realised we haven't received the act so let's resend and we send the original data again and that's going to arrive assuming there's no problems from now on and eventually we'll send back the act assuming there's no more losses along the way and I'll just keep what happens next from the destinations perspective B received the first data frame at this point in time frame one increased my account balance to 10,000 because of the act was lost A retransmits that same piece of data B receives the same piece of data message one again the data is increased Steve's account by 10,000 but what happens nothing well that's what should happen if B receives this data and processes the data we'll have a problem because what was sent was increased by 10,000 decreased by 2 decreased by 1 so the final balance should be 7,000 but if because of the protocol we retransmit because of the lost act if the process this data and increases my account by another 10,000 we're going to have a problem we haven't achieved what the intended data transfer was built for so in this case what B does is ignores this piece of data so in the case where an act is lost and A retransmits even though B has received the data before it receives it the second time same data in this case B must ignore this data discard the data so it receives it, looks at it detects that it's the same as the previous one I received and throws it away because if it didn't discard the data my account balance would now be 20,000 baht which is incorrect so in this case it's important to note B receives the data but discards it it ignores the contents any questions there should be one question at least how does B know how does B know that this data is a retransmission of this data it may have been that there were two messages data one was increased my account by 10,000 and data two was a distinct different message but in fact also said increased by 10,000 maybe that's the intended operation increased by 10 plus 10 to 20,000 how does B know that this data message received is in fact a retransmission of the first one received it's the sequence number and if we go back and draw those sequence numbers you'll see that A sent data with sequence number 0 B sends back an act saying the next number A expect is 1 A doesn't receive that timed out and retransmits the original one which used the same sequence number 0 B receives this frame B was expecting sequence number 1 but received data with sequence number 0 it's unexpected therefore B knows to ignore this it must be a retransmission of some previous piece of data I received so B ignores the data but still sends back an act with act number what act number here is an act what number does B send back in it you've got two guesses 0 or 1 left hand up for 0 right hand for 1 it's 1 it's your right hand it's the next number expected from A we still expect 1 we just receive 0 ok sent back act saying I expect to receive 1 I just receive 0 again that's a retransmission throw it away discard send back an act saying I'm still waiting for sequence number 1 and hopefully the next one that comes we won and we can keep going assuming no data loss the second data frame delivered and processed in the third one this is why we include or need sequence numbers in stop and wait so that B in this case of a lost act can distinguish this frame is just a copy or retransmission of the previous one discard if I could not distinguish and if I process this retransmission I would have increased my account to 20,000 minus the 3,000 at the end I would have made 10,000 bar which is wrong so the case of a lost acknowledgement of course our data doesn't have to be financial data it can be anything it can be part of an image, a file but the same thing applies we need to detect retransmissions and discard them where necessary so that the final data received at the application or by the user here is in fact an exact same copy as what was at the user at the source so we've got three examples the normal case that's easy we have sequence numbers and we've looked at a case with lost data and a lost act just going back to our description this is our description of the protocol source transmits a single frame starts a timer stores a copy of that frame if we receive the act before the timer expires fine move on to the next frame if the timer expires before receiving the act then retransmit that copy in practice we have a limitation on the number of retransmissions let's say I send data it doesn't arrive, it's lost so I retransmit and that doesn't arrive and it's lost so I retransmit again and again and again well I don't go forever I must eventually stop retransmitting and accept the fact that my data is never going to get there and maybe present an error saying I could not send the data so we have a limit on the number of retransmissions we have frames with a one bit sequence number we need this one bit sequence number there's zero one alternating for that special case of if we receive a retransmitted data segment because of a lost act the destination can detect that and discard that that's the purpose of the sequence numbers simple but the same as stop and wait flow control can be inefficient we still have this issue of send some data wait a long time before we can send the next piece of data so the same inefficiencies of stop and wait flow control before we look at using the sliding window mechanism to improve the efficiency of our queue now's the time to ask people looking through the lecture notes next scheme we'll go through is called go back end and it's based upon sliding window mechanism where we can send W frames before we have to wait for an app but we also have a retransmission scheme so think we have the sliding window flow control but also as in the sliding window if there's no errors then it behaves just like the sliding window mechanism so we send our data and acts come back so if the destination receives the data it sends back an act containing the sequence number of the next expected frame that's what we've seen all along in practice it may not be an act for every data frame received it may be every second or every after every time period now what if an error is detected that is destination detects something's gone wrong then it can reply with a negative act saying I've detected something's gone wrong please resend or please fix it so in stop and wait we have had a positive act we send our data we receive an act indicating it was successful we have a positive act in sliding window if there's no error but we also have a negative act saying destination has detected something's gone wrong therefore it requests the source to fix that negative act or sometimes a reject message rejection message now what does the source do to fix the problem when the source receives this negative act telling it something's gone wrong it in fact contains the an act number saying the next number expected by the destination and that triggers the source to retransmit and we'll see importantly compared to our third approach the source will need to retransmit where we here the transmitter the source must go back and retransmit all the frames since that lost frame and that's where the go back and name comes from we go back and retransmit and frames not just one frame there are a few other features but let's go to the example this is a diagram slightly different from what we've drawn it just hides the details of the frame transmission so it just shows frame 0, frame 1 and so on because there are many frames to keep it condensed A has many frames to send to B in this example we have a window of 7 frames so we see our sequence number you'll eventually notice goes from 0 up until 7 and then wraps back to 0 so frame 0, 1, 2, 3, 4, 5, 6, 7 frame 0, 1, 2, 3, 4, 5, 6, 7 so in this example we still have sequence numbers as in sliding window in this one it goes from 0 to 7 a 3 bit sequence number the first what 4 frames arrive at B successfully frame 0 1, 2 and 3 they all arrive at B and in this example B is sending an ACK for every second frame so it could have been an ACK for every frame but I think just to keep the diagram simple we're drawing an ACK for every second frame receive frame 0 receive frame 1 send back an ACK and another another name we saw was this request what do we call it? request reply indicating the next number expected frame 0 has arrived at B frame 1 has arrived at B we now expect frame 2 so we see RR2 an acknowledgement positive ACK saying I now expect 2 frame 2 arrives at B frame 3 arrives at B we send back an ACK saying I now expect 4 nothing's nothing's gone wrong at this moment everything's okay frame 4 was transmitted by A remember A has a window of frames it's allowed to send as in sliding window we're allowed to send many frames before waiting for an ACK A has sent frame 3 4, 5, 6 frame 4 is lost it doesn't arrive at B so we have bad luck at this point and we lose frame 4 we arrive at B frame 5 is not lost it does arrive at B the arrival of frame 5 at B tells B that something's gone wrong because from B's perspective it's received frame 0 1, 2, 3 and then 5 B expects to receive the frames in order that's how we use our sequence numbers we've received a frame out of order we've received 5 before we received 4 that tells us something's gone wrong 4 has been lost in this case so that triggers B to send this negative ACK or reject message back to A saying something's gone wrong I still expect frame with sequence number 4 whether you see a reject 4 message here and that frame 5 that was received by B it's thrown away it's not stored in memory we throw it away even though we successfully received it from B's perspective it must receive the data in order if it's received 0, 1, 2 and 3 the next one it's going to accept is 4 if it receives 5 throw it away 6 discard it's just a simple procedure for the receiver if you don't receive a frame in order discard that frame when A receives the reject message that tells A that it needs to retransmit frame 4 A has sent frame 4 but then it receives a reject message with ACK number 4 telling A something's gone wrong most likely A, frame 4 has been lost therefore we need to retransmit frame 4 but we also need to retransmit the frames we've sent since frame 4 so A has sent 0 through to 3 4, 5 and 6 B tells us frame 4 you need to send again in go back N in fact A needs to go back and retransmit 4, 5 and 6 those all 3 frames and we see that here 6 are retransmitted this places the this makes it easier for the destination in that when the destination receives a frame out of order it simply discards it it doesn't need to store it in memory it uses less memory at the receiver but as we'll see compared to the next approach it introduces extra retransmissions which is bad for efficiency because in fact frame 4, 5 and 6 5 and 6 were received only 4 was lost but with this scheme we need to retransmit 4, 5 and 6 that is the lost frame plus any sent after the lost frame but before receiving the reject and in this case so far 4, 5 and 6 arrive successfully so we get an Ack back saying here we receive 4 B receives 5 and 6 7 is expected let's stop there questions when we when we calculate efficiency and also throughput think of throughput is the rate at which we receive the real data original data so what real data has been received frame 0 or the data inside frame 0 1, 2, 3 4 was not received at this point even though 5 and 6 were received by the B they were discarded so we do not count them as real data being received it's only until at this point we receive 4, 5 and 6 the retransmitted values do we count that data as efficiency this is somewhat inefficient in that 4, sorry frames 5 and 6 arrived but were discarded and we actually had to resend them wasting some time but that makes it the reason for doing that is to simplify what B the destination has to do it just receives frames in order we'll go through the last part in a moment that's an extra feature for any other questions so we use the sliding window we retransmitted we use a negative acknowledgement telling the source that something's gone wrong and that is sent when the destination recognises a frame has been lost because it receives one frame out of order expecting 4, receive 5, tell A to resend 4 and resend 4 and all subsequent frames that you've sent in this example 4, 5 and 6 let's for now skip the last part and look at an alternative called selective reject very similar except if we see the same scenario 4 was lost, 5 arrived 6 arrives compared to go back in what B does is those 2 frames indeed out of order frame 5 and 6 it stores in its buffer sends back a reject message or a selective reject really you think that means B is telling A please retransmit frame 4 and in selective reject we only need to retransmit that one frame so we see A sends 0, 1, 2, 3 successful 5 and 6 B does not receive 4 receives 5 instead sends back this negative act saying please resend 4 here it stores 5 and 6 for future use A receives the selective reject message and retransmits 4 and then moves on to the next frame after 6 so 7, 0, 1 if we compare between so far go back in and selective reject just in the first portion in go back in we need to go back and retransmit all frames since the lost frame 4, 5 and 6 in this example that is easy for the receiver because it does not have to store frames received out of order but is inefficient because we retransmitted 2 frames which are actually delivered whereas with selective reject we only need to retransmit 1 frame we do not need to retransmit 5 and 6 because 5 and 6 are buffered by the receiver so selective reject is simpler, sorry is more complex for the receiver requires more memory and more processing to put frames back into order but is less is more efficient because we only need to retransmit 1 frame go back in is less efficient but simpler than selective reject selective reject requires extra memory more complex at the receiver but can be more efficient than go back in so they are very much very similar those to just for that the way that the retransmission occurs so the variation in the delay and the selective reject in fact it can get quite complex especially when we have things like losing 2 frames and the selective reject normally indicates we are saying this indicates 1 frame to be retransmitted if we lost 2 frames in this case what happens or what if the delay between 2 frames varies significantly that has a impact on the efficiency and we are not going to discuss and analyse in that level of detail we will just say comparing the 2 approaches selective reject in most cases will be more efficient than go back in in the most typical cases in some cases it may not be or it may be equivalent what do we miss almost done the extra features the bottom of the diagram is that we still have a timeout mechanism so far we have seen with go back in and selective reject we retransmit when we receive a negative act because the destination recognises something went wrong because the frames arrived out of order but as with stop and wait acts can be lost we send frames the act sends back but it doesn't get back to A if we don't receive the act in time we may have a timeout that says let's do something about it and what do we do there's a special message which requests a reply or requests an act from B that's this special message here saying we are waiting for an act we are waiting for an act we don't receive an act because it was lost let's request an act from B hopefully it won't be lost this time the act comes back and that tells us that we can move on to the next frames so there's this extra feature to request an act from the destination an act request or this RR message with some special bits to indicate it's a request the same applies in selective reject the same from that feature's perspective try and pick up the main points between the difference of these three ARQ mechanisms stop and wait ARQ almost the same as stop and wait flow control but we now have retransmissions and the basic scheme is if we don't receive an act within some time period retransmit with go back in and selective reject we use sliding window we're allowed to send W frames or a window size of frames we detect errors or we detect lost data at the receiver when it receives frames out of order because if we send seven frames and we receive all but one of them then we detect which one's missing and ask the sender or ask the source to send again go back in selective reject based upon sliding window go back in and to finish here selective reject compared to go back in minimizes retransmissions which is a good thing compared to go back in but it requires the destination to maintain some buffer to receive frames out of order which requires also more complexity to put them back into order so they're the disadvantages of selective reject compared to go back in turns out that go back in is more widely used even though it's less efficient the simplicity makes it an appropriate trade-off selective reject is used in some cases when efficiency is very important in this case all three of those ARQ schemes are used in protocols and in systems today or variations upon them 10 minutes finish this topic we've skipped one slide we need to go back to it but before we do all of these ARQ schemes especially stop and wait need at some time out period we send our data we wait for the act to come back how long should the time out period be if I ask you a question in the lecture how long should I wait if I wait forever if I wait forever we will not communicate much in this lecture you will not learn much because I'll ask you a question at the start and I'll stand here for one and a half hours how long do I wait before I for example retransmit that question maybe you didn't understand maybe you didn't hear me so I ask again the question well this is the time out period I send some information to you if that information is lost along the way then I should retransmit so how long do I wait before I retransmit that's an important thing now what if I say what is your name what is your name what is your name what is your name in that case I'm asking a question I'm sending data I'm waiting for a response a very small amount of time before I re-sent I sent the message I did wait for a response but I didn't receive a response within half a second so I re-sent the message it was very inefficient because he was trying to think of his name he knows it he would have said he was sending me his name but I didn't wait for it to arrive so we need a trade off a time out period which is long enough to give the receiver a chance to reply but it's not too long such that the source waits a long time before retransmitting if there's an error so we need to choose a time out that deals with this trade off how long should it be well as we said long enough to get an act back if there's no loss of data well how long does it take to get an act back it depends upon many factors it depends upon our link our data rate, our propagation delay processing it may in fact vary so it's actually although we can propagation time may be variable processing may be variable it's hard to estimate how long it takes to get an act back so with real links so usually we need to set it quite large so if we estimate the time to get a response back is 1 second then well maybe we give it some freedom and set it at 1.5 seconds because sometimes things vary now we could set it at 10 seconds so give us enough time to get a response back but the problem there is if it's too long then if we send our data and that data is lost 10 seconds before we retransmit we spend a lot of time waiting wasting our resources not standing so too long waste the sources time before it retransmits if data is lost a timeout which is too short leads to many retransmissions which are also wasteful of our network resources or our link resources so choosing a good timeout value is in many cases difficult and usually protocols either define what the timeout value should be or have an algorithm for calculating or estimating what it should be based upon what's happened in the past for example yep and so in some data link layers like in your LAN well what does the time depend upon propagation time data rate well if you know those characteristics then the device can calculate what it may be if we know the distance or if we can test what the propagation time is then we can estimate the timeout period yep so but we need to know in advance or we need to determine it in advance so that the source knows how long it needs to wait before it retransmits in general it's difficult to work out what is the optimal timeout period in practice but it needs to be decided that's one design issue with all of these protocols retransmission protocols the last few slides you'll have a look just some examples of some specific protocols that use these retransmission schemes there are many we need to jump back one more slide here here it applies to all of these schemes both flow control and error control we talk about sending frames frames of data how big are the frames usually a protocol a specific protocol places a limit on the size of the frame the upper size upper limit that is for example most LANs Ethernet LANs in the normal case the frame size can contain no more than 1,500 bytes of data that's an example value means if I draw my frame we may have a header and some data we may have a trailer as well a protocol or a standard would specify how much data can we put in here usually as an upper limit one example may be 1,500 bytes meaning we cannot put more into that one frame so if this is the maximum size of our frame if the data descend I have 3,000 bytes then I would normally create 2 frames split it into 1,500 each if the data descend was 1,501 bytes I would have 2 frames 1 is 1,500 and the other one most likely 1 byte if the data descend is 1,500 we'd have 1 frame if it was 10 bytes then we'd have 1 frame so we usually have a limit on the maximum amount of data to put in the frame what is the optimal value well there's a trade-off the larger the frames the more efficient we are with respect to the overhead the header think of this picture if I drew it to scale we have a header normally that's fixed in size let's say let's give it a number 20 bytes which means if we have 1,500 bytes of data we have an extra overhead of 20 bytes so in this case we'd send 2 frames so we need to send 40 bytes of overhead but if our frame size was increased to 3,000 bytes in the first case when we have 3,000 bytes of data to send we'd send just 1 frame if we could fit it all into 1 frame as opposed to 2 separate frames we reduce the overhead because with 1 frame we just have 1 header of 20 bytes with 2 frames we have 2 headers totaling 40 bytes of overhead so the larger the frame the lower the overhead of the headers so we want a large frame for that perspective but there's some reasons for a small frame consider the middle point if we send a large frame let's say we have 3,000 bytes of data to send if we send 1 large frame of 3,000 bytes and there's 1 error then we need to retransmit that entire 3,000 bytes but if we send 2 smaller frames and there was just 1 error it means 1 of the frames would be received correctly we only need to retransmit 1 of those 2 frames we only need to retransmit 1,500 bytes so generally in the case of retransmissions we'd like to retransmit just small frames we don't have to resend so much so we want smaller frames from that perspective another case maybe the buffer size of the receiver if we have a buffer of it's a bit hard to illustrate if we have a buffer of 4,000 bytes if our frame size is 3,000 bytes how many frames can we receive in the buffer how many 3,000 byte frames can we receive in a 4,000 byte buffer just one okay what if our frame size was 1,000 bytes how many can we receive we'd receive 4 that is our frame we may be more inefficient in filling up the buffer with a 3,000 byte frame we only use 3 out of the 4,000 bytes of the buffer but with 4 1,000 byte frames we could fill up the buffer so in fact generally we want to use smaller frames so we can be more efficient using the memory at the receiver the buffer at the receiver there are some other reasons as well oh, it's a trade-off large frames minimize that overhead due to headers small frames for various reasons make efficient use of buffers reduce the overhead if we have to re-transmit and there's some other things like sharing amongst multiple users in practice usually the upper limit is determined by the protocol wired lands 1,500 bytes is the typical upper limit smaller but that's usually an appropriate trade-off for that type of network so there are two design issues how big should our frames be and what was the other one how long should our time-out be important design issues out of time, finished on this topic tomorrow I will not teach you on Wednesday we'll cover the next topic of circuit and packet switching we're going to skip multiplexing we'll see you then