 In the previous topic we got to error detection and error correction. We have frames, we send across a link. The frame is made up of some payload, the actual data, and some header, or maybe trailer, where the header and trailer are some extra information that support the data transfer. And we'll see some more examples of what the header and trailer look like as we go through different protocols. So we send a frame across a link. One of the issues we have is what if we have errors in that link? It means what's received is not the same as what was transmitted and we need to first detect those errors and then, if possible, correct the errors. So we saw, say, parity bit as an error detection scheme and this Hamming code based error correction, forward error correction. We're going to look at some other ways to correct and detect errors and the ways that they detect and correct errors use similar techniques to another purpose of what will go through today's flow control. So the techniques for correcting and detecting errors are classified as automatic repeat request schemes, or ARQ schemes. We'll cover them eventually, but it turns out they're very similar to the schemes that it performed for flow control. So today we'll introduce what is flow control and some of the basics of the protocols for flow control and ARQ. First we need to say, well, what do we mean by protocol and how can we try to analyze and understand what a protocol will do and how will it perform? How can we analyze it? Quite simply we can say a communication protocol, it's a set of rules, a rules that the computing devices which are trying to communicate must follow. There may be two entities involved, or in some cases more than two involved, but the most of the examples we will see, there are two entities. A sending to B, for example. What rules do they follow such that they can communicate correctly and efficiently? So a protocol will define the rules that include defining the entities involved. For example, give them names like a client and a server. A web browser communicates to a web server using a protocol called HTTP. HTTP defines the involvement of those entities. They send messages. Generally we call them messages. We've been speaking about frames. The entities send messages to each other. What types of messages and what are the structure of those messages? For example, a protocol may say that computer A sends a data message to computer B and computer B must respond with an acknowledgement message saying I've received your data. So we'll see an example where protocols may use say two types of messages, a data message and an act or acknowledgement message. In addition, the formats of those messages are defined. The formats really mean the structure of the frame. How big is the header? What fields are included in the header? How big the payload may be and if there's a trailer? So that must be defined in advance. And sometimes there are assumptions about well if we send these messages what do we assume about the underlying mechanisms? Are there any errors in the link? Do we need to deal with those errors? And protocols are designed by people and usually they become a standard. So there's a standard for data communications via wireless LANs. So from my laptop to the wireless access point, the frames that my laptop sends to the access point, the structure of those frames, when I can send how often is defined in a protocol and that protocol is inside what's called the IEEE 802.11 standard. The people who design protocols have some difficult tasks to get them correct, to make sure that they don't make mistakes when they design them such that for example a situation where my laptop wants to send to the access point but it's waiting for a response for the access point and the access point is waiting for a response from my laptop. So we get into some deadlock where neither of them will send because they're both waiting for a response from the other. So the protocols need to be designed such that that state doesn't occur. So they need to be correct. They need to perform well usually. We often care about performance like minimizing delay, maximizing throughput and other metrics. And be secure. We do not cover security in this course because it's important that any communication protocol nowadays be designed such that people cannot extract information that they shouldn't be able to extract from that communication. We're not going to look at the techniques for ensuring correctness, maximizing performance or security. We're going to use a very simple technique to draw protocols and do some simple analysis of their performance. We'll call message sequence charts or time sequence diagrams. And I think we've seen one before but I'll try and explain it. The type of diagram we'll use and we'll go through an example, get you to use it. We need this because in the subsequent discussion we're going to use them to illustrate the protocols. I think we will not go through that. We'll go straight to the example here. This is the type of diagram we'll commonly use to illustrate how a protocol works. And then we'll use it in our course to analyze the performance like delay and throughput. So first let me explain what the diagram shows. This is what we'll call a message sequence chart or a time sequence diagram. In this example there are two entities, two computers involved, A and B. The vertical line under A and B that indicates what's happening at computer A and the things that happen on this line indicate what's happening at computer B. Remember there are different end points at the link so they have different observation about what's happening when they communicate. What we want to show is the transfer of frames between A and B and the timing for the transfer of those frames. So the way that we'll draw it, in this example let's say, well first for this vertical line as we go down time increases. Imagine we start out two computers and they're going to use some protocol to communicate and at the start we start a timer, a stopwatch so the initial time is zero and the timer increases. Graphically think if this time is zero as we go down the timer is increasing so this will be greater than zero down here. So we're showing that the sequence of operations as time increases. In this example let's say that at computer A the human user has pressed a button, send and that triggers the protocol to send a frame from A to B. How would we draw that? Well when the user presses the button send at some time say at this time it triggers the protocol to start transmitting a frame and the way that I'll draw the transmission of that frame is this rectangle here. So this rectangle means a frame is being transmitted from A and it's going to be during that period of time. The frame has a number of bits in it. It takes some time to transmit and you can calculate the transmission time by the data size divided by the data rate. So visually we'll say we start transmitting here after some time we'll end transmitting. So the time between this point and here is the transmission time of that frame. When A starts transmitting the frame we can think that the signal representing the first bit of that frame comes out of that computer A and starts travelling across the link and it propagates across the link and we know it takes time to propagate across the link. We can calculate the propagation delay. So when A transmits the first bit at this time from the receiver B's perspective some time later is going to receive that first bit. So I show that if we transmit here the reception will start at a lower point and the difference in time will be the propagation time. The difference in time between this point and here is the propagation time of the link or the network. So we can think if A starts transmitting here B starts receiving some time later and then B continuously receives the signal for that transmitted frame and eventually receives the last bit and in the protocols we consider B will not do anything with the frame until it's received it it's in the entirety. It must receive the full frame before it does anything with it. It's not always true but in the simple cases we'll consider we'll assume that B can't do anything with the frame until it has all bits of the frame. Once it has the entire frame B may look at the frame check if it has any errors do some processing and then use the data in there. For example you use a computer A press send it sent an email or a frame containing the email to B. When B receives that entire frame the data inside the email is eventually displayed or sent triggers a notification at the computer B's application so the data gets used once the frame is fully received and processed. So the point is we're going to use such diagrams to illustrate the exchange of messages here we just have one frame from A to B but another protocol could have B sending a frame back in return. So we draw a rectangle being transmitted by B coming back to A and once we have such diagrams we can do some simple analysis of the delay how long does it take from one point to another and the throughput will look at how many bits per second B can receive. So let's do that with an example so you're clear on what type of diagram so write down some characteristics of the link and our data and you'll draw a diagram I want you to draw a diagram like this you don't need to label the words and these dashed arrows just the solid line for A and B and the frame being transferred and in addition to drawing a diagram like this in fact your diagram will look almost identical to this I want you to label on there we start at time zero if this is time zero and I write a zero here what is the time at this point what is the time at this point that's your task so let me give you the the link characteristics let's say for our case we have a link from A to B and the characteristics of that link it's a distance of 2 kilometers the data rate is 1 megabit per second and the transmission speed our signal speed we've often assumed the speed of light let's make it a bit simpler instead of 3 by 10 to the power of 8 we'll have 2 by 10 to the power of 8 meters per second this is the data rate of the link this is the speed of the signal transmission and this is the distance the length of the link 2 kilometers and we want to send a frame first we'll focus on just a single frame from A to B and the frame is made up of 20 bytes of header plus a thousand bytes of payload so given that information I want you to draw the picture and it's going to be the same as the one on the slide but I also want you to label the times of when we start transmission when we finish transmission and when B receives the entire frame at least three numbers you should label on the picture and then we'll add some more frames to it so just spend five minutes you'll need to calculate transmission delay propagation delay we'll assume so far no processing delay so you only need transmission and propagation and then label them on your picture so draw a diagram essentially identical to this one but label here the start time the end transmitting time and the receive time so in our example we want to draw a picture which will look like this but we want to also label the timing on that so we need to know the transmission and propagation delay let's do the transmission delay first and I'm going to we'll have different types of frames later this one is a frame that contains data let's give it the name data because some of our examples later we may have a different type of frame so refer to this one as a data frame so the transmission time is the data frame data rate sorry data size 1,020 bytes header plus payload divided by the data rate one megabit per second 1,020 we have bytes and bits per second so we should have the same when we do the division so let's convert this to bits at the top so 1,020 times 8 is 8,160 bits so now we have 8,160 bits divided by one mega bits per second divided by one mega we get one micro and bits divided by bits per second become seconds 8,160 micro seconds and the other thing we need to know is the propagation delay from A to B how long does it take the distance 2 kilometers divided by our speed of transmission is 2 by 10 to the power of 8 2,000 meters divided by 200 million 2,000 divided by 200 is 10 we get 10 divided by 1 million we get micro seconds again so we have our propagation delay and our transmission delay and we're assuming no processing delay here so we can use those numbers and we'll label the time on our time sequence diagram so we think at the start A starts transmitting a frame so I'll draw that as a rectangle being transmitted this rectangle is showing that this is our data our data frame and I'll call it data frame number 1 because I'll transmit some more in a moment but for now it's just our first data frame and let's assume we start our timer when we start transmitting that's the first thing we do in this case so I'll label this time as time zero so the time in micro seconds instead of writing zero micro seconds I'll leave off the micro seconds just write zero so we start transmitting at time zero it takes 8,160 micro seconds to transmit therefore we'll finish transmitting at this time 8160 so all we're doing here is drawing a rectangle indicate this is a frame transmitted it's a data frame and it started at zero and it finished at 8160 in micro seconds but to get to B is the other thing we're concerned about how long does it take until B receives that frame in its entirety we can think if A starts transmitting at time zero the signal comes out and then it propagates to B it takes some time to propagate the signal representing this is the first bit of our frame then we transmit the second bit out of computer A the third bit and so on so the signal representing the first bit transmitted propagates to B if it was transmitted at time zero it's going to arrive 10 micro seconds later arrive at time 10 the timer we're using at both A and B is the same okay it arrives at time 10 at B first bit but then it receives the second bit the third bit and I'll not draw lines for all of the bits what we're usually interested in when do we receive the last bit when do we get the entire frame 8,170 not so hard is it if we transmit it at 8160 it takes 10 to propagate so we get the entire frame at 8170 so that's to what I mean by labeling our diagram with the timing not so hard in this case but it can be useful when we want to consider total delay to do something in a particular protocol and calculate throughput note that my pitch is not to scale it's very hard to draw it to scale because this is 8000 this is only 10 but I cannot do that so we label the times to make it clear when different events occur start at time zero start transmitting finish transmitting from A's perspective at 8160 B finishes receiving at 8170 let's continue let's say A has an infinite supply of data to send to B so what does it do next A has more data to send well from A's perspective it's transmitting at time zero to 8160 it finishes the first frame it's got more data to send so it will transmit a second frame so we'll draw the second frame and when the second frame is finished it will send the third frame and just keep sending every simple scenario where it just continuously sends frames all of the same size to B let's draw a few more frames and draw the timing on those frames after A transmits or completes transmitting frame number one again let's assume there's no processing delay it can immediately move on to frame number two data two when will it finish transmitting data frame two if it starts at 8160 when does it finish it's the same size frame as frame one it's still a thousand and twenty bytes same size same data rate or same transmission delay so another 8160 microseconds just add on 8160 16 320 the frame now here we're we're not going to we've got a line effectively showing the start of the transmission when does the second frame arrive at B if we start if we transmit the last bit at 16320 then it arrives 10 microseconds later 16330 and you'll see that there just continues that pattern of an extra 8160 each frame we're not going to draw many data frame three data frame four and the timing an extra 8160 480 from here to here and then to transmit frame number four another 8160 and if frame number three will finish transmitting at 24480 it takes 10 to propagate and the fourth frame arrives at 32550 and we could keep going but I think you see the pattern from A's perspective it's transmitting a frame every 8160 microseconds which just keeps going and from B's perspective it's transmitting a frame every 8160 microseconds and that's something we're interested in because that's an indicator of throughput from B's perspective it's doing nothing at time zero so at time zero B is not receiving anything it's sitting there waiting but then at time 10 B starts receiving it starts receiving the first frame it receives it it spent 8160 processing maybe it does some processing but we're assuming that it's zero here then it starts receiving the second frame and it takes 8160 microseconds to receive the second and the third and the fourth and each subsequent frame let's make note of that and look at the rate at which we receive B receives one frame in 8160 microseconds here and then in this period it's another frame received in the same period same time and so on so let's look at now the rate at which we receive frames we can say B receives one frame every 8160 microseconds if we continuously transmit data from A it would always be one frame per 8160 microseconds what we care about is the throughput and the throughput we define as the rate at which B receives payload not the rate at which it receives frames but the bits per second considering the payload only not the header so B receives one frame every 8160 microseconds one frame contains 1000 bytes of payload plus 20 bytes of header so we can say B now receives 1000 bytes of payload every 8160 microseconds payload is the actual data the thing that the users are interested in from that we can determine the throughput the rate at which we receive payload 1000 bytes every 8160 microseconds and you'll use your calculator to find out what that is how many bits per second B is receiving payload at can anyone tell me the last three numbers 9,5 I remember the first three 9,5,9 something something something 8,000 bits divided by 8,160 microseconds gives us someone with a calculator divided by 81960 ok not 9,5,9 I remember the wrong number 980392 980392 bits per second we can see now if A continuously transmits frames without any breaks then B will continuously receive frames one frame per 8,160 microseconds every frame contains 1000 bytes of payload so that gives us our throughput of 980392 bits per second what was the data rate back to our original question we had a data rate of 1 megabit per second how efficient are we in using the link in delivering payload about 0.98 or 98% I have a link that allows me to send bits at 1 million bits per second but in my frame I'm not just sending payload I'm also sending header so I actually have 20 bytes of header plus 1000 bytes of payload so that gives me an efficiency of about 98% about 98% of the time I'm sending payload the other 2% of the time I'm sending header through the link and from the user's perspective we care about the payload being delivered of course we need to include the header because the protocol usually needs it to support the correct operation but from the user's perspective they're getting 98% efficiency which is good now there are other ways to calculate that if you look at in this case 1000 bytes out of 1020 1000 bytes it's also 98% it's the same approach but when we look at some later examples we'll see that we should use this approach to calculate throughput and efficiency not just consider the payload and frame size any questions on the calculations for this very simple case and the drawing of the picture and I think since we're on drawing these pictures and doing these calculations instead of explaining flow control we'll leave that till next lecture we'll go through another example of a slightly different protocol and see how they compare and then the next lecture tomorrow morning we'll explain why we would have a different protocol in this case the protocol was very simple just send frames the protocol defined the frame size we defined up front 1000 bytes of payload 20 bytes of header but there was no exchange between A and B A just sends data as fast as possible that's not very common usually we'll see that there's some feedback from B A sends some frames to B and B may reply with some information maybe indicating whether there was successful transfer or not and we'll also see that B may reply to slow down A so we'll go through an example and without explaining the reasons yet why we'd send back a response but we'll go through an example calculation where every time A sends a frame to B B will send back a reply message and the purpose of the reply message is just to tell A it can send a new frame so this new protocol will be A transmits one frame when B receives that frame B will send back a special frame which we'll call an acknowledgement an AC think it's B receives a frame and sends back a short message saying thank you for that frame I'm now expecting another one from you and when A receives the acknowledgement A can send the next frame onto B when B receives the second data frame it will send back an AC so instead of continuously sending data A will have to wait for the acknowledgement to come back before it sends data frame 2 and then wait for the acknowledgement for data frame 2 to come back before it can send 3 let's consider that protocol I want you to draw a time sequence diagram for that protocol and let's give you one more piece of information let's assume that AC frame is 20 bytes so we use the same values here the data frame still 8160 microseconds propagation delay is still 10 microseconds but we'll add in some more let's assume that we have a second type of frame called an acknowledgement an AC and this AC frame doesn't contain any data any payload it's just something B sends back to A something thank you it's like A sends some data to B B sends back a thank you message then A sends some more data B sends back a thank you message an acknowledgement so it's in fact just 20 bytes in our example in other examples it will not necessarily be 20 bytes it's just for this calculation it's header only no payload what's the transmission time of our AC frame now same data rate we have just 20 bytes to transmit we have 160 bits at 1 megabit per second 160 microseconds our data frame was 8,160 bits in fact 160 bits with a header here we just have the header no data so it's 160 microseconds to transmit the AC what's the propagation delay from B to A going in the opposite direction from A to B it was 10 microseconds so from B back to A it's also 10 same distance same speed so same propagation delay that's quite common and the rules of our protocol which are different from before rule 1 AC before moving on to the next frame if we fit that in and the second rule in our case just to summarize our protocol in this case the rules are A after transmitting a frame we will start by transmitting a frame it will wait for an acknowledgement of that previous frame and it will wait to receive the acknowledgement in its full before it will transmit the next frame and from B's perspective the receiver of the data when B receives data it will immediately send back an AC there may be different rules and different protocols but that's what we'll consider today and well maybe not immediately let's add in another thing when B receives the data it sends back an AC after one microsecond after processing receive the data process then send back the AC we'll add in some processing time for this calculation and that's just to illustrate that our timing diagram can capture different delays given that draw our timing diagram and calculate the total time to complete a single data transfer what happens if you send try and draw, say, three data frames being sent from A to B and then finally we'll look at the throughput I'll let you try and draw the timing diagram first and then we'll calculate the throughput at the end we'll start by A transmitting the data at the start it's going to be the same as our previous case start at time zero it's 8160 B receives or starts receiving at time 10 finishes receiving at 818170 this is the same as before from A's perspective it's transmitting the first data frame it finishes it's got more data to send but in our protocol the rule says we cannot send more we cannot send the next one until we receive the AC for the previous one tomorrow we'll talk about why we would do that but let's just look at the performance for now so A at this point cannot do anything it cannot transmit it must wait wait for an AC to come back so let's look at B B receives frame one at time 8170 then we said there's some processing time hard to draw it's a small amount of processing here and it only takes one microsecond so the processing finishes at A171 so there's some processing time we're not transmitting we're not receiving we're processing the previous frame then we send back a thank you message to A I've just received the data I send back an acknowledgement saying thank you for the data please send me more we call that acknowledgement in short an AC and it should be smaller the data now my again the scale is not to scale but we can see the main idea this is AC this is the first AC we said how long does it take to transmit an AC we said 160 microseconds so if we start at 8171 add on 160 we'd finish at 8331 is that right? yep if we start at transmitting at 8171 the propagation delay from B back to A is 10 so we'd start receiving the AC at 8181 that's receiving the AC and we'd finish receiving at 8341 now we don't have to always draw all of these times especially when we start receiving that's not of interest we care about when we get it the last bit because we'll assume that we must get the entire frame whether it's data frame or AC frame before we do anything with it that's common so this is the scenario we have for the first data frame A transmits to B B processes sends back the acknowledgement once A has that first acknowledgement it checks it second data frame so we get with the second frame being transmitted now and when B receives that second frame it's going to process for some time and then send back an AC so this is data frame 2 and this is AC 2 the second AC and the timing that we have here remember everything's the same in terms of frame size and propagation delay so it's again 8160 so we add on 8160 and we get 165 0 yes why is there one microsecond delay here because just in this example I introduced a case where I said B gets the frame it's a slow computer it needs to process and let's say it takes one microsecond to process I could have said 5 microseconds or 10 seconds but just to introduce a different time in here and each frame will take one microsecond what do we get add 160 we get 5101 501 running out of space with one microsecond processing delay then we transmit back this is the one we care about when we finish you can check the numbers in here but if you look closely if you look at the first frame we started at 0 we ended at 8341 the next frame is exactly the same that is we do the same steps so it's going to take the same time and the difference between 8341 and our 16682 is 8341 so the time for each phase is the same in this case this is a different protocol the role of the protocol the reason for sending the act we'll discuss tomorrow but for here just see how we draw it and calculate the timing you'll go home tonight and calculate the throughput in this case calculate the throughput and efficiency and tell me the answer tomorrow