 So, flow control and error control in terms of asking me to resend are what we combine together and call part of protocols that support delivering the data across the link efficiently. And we give them a name data link control protocols, controlling the data communications across the link. Up until now we've mainly focused on signals. And now we're talking about messages, also called frames or packets, like our envelope contains some extra information and the data. And last week we ended up with a picture of a frame, data plus header and optionally trailer. We want to get these messages across our link efficiently and the different ways for doing that are classified as data link control protocols. There are many things that need to be done to make sure we can efficiently communicate across a link. Two of them, flow control and error control. That's what this topic will talk about. But there are some others. In my example we had a source address and a destination address. So again, what's the format of the addresses is part of these protocols. That is, a computer doesn't use a name like Steve, but usually we use some binary value to represent the computer. So the address formats and how to get addresses are also needed in data link control protocols. So addressing, where is it here? Sometimes in some systems before we send data we need to tell the other one that or check with the other ones ready to receive data. So there are some aspects of setting up a link or maintaining a link. And there are a few other things necessary to make sure that we can communicate across a link. We're going to focus just on flow and error control. We may see some more examples of addressing in later topics. And we talk about all these features as data link control protocols or in the layer of protocols called the data link layer. And I think the next topic, which you don't have lecture notes on, we'll talk about more generally what a layer is, not so important right now. Let's go direct to flow control. How do we make sure we don't overflow the receiver? And this tries to draw from a computing perspective what happens when we send data to it from transmitter to receiver. This rectangle is the transmitter, the source device, and this is the receiver. We start with some data, I call it a packet in this case, but we have some data to send from source through to destination. The source, if you notice what I was doing, I had a lot of data to send and I had it storing in my hand. I stored that data in my own buffer memory or queue. The memory is the implementation of what we sometimes call a queue or just a buffer. So I store that before I send it. And then I create this message, I attach the right on the source address, the destination, I check, calculate the parity bit, set the sequence number. So I create the message, this is this processing the frame, and then I transmit it. Now this is illustrating I have a bunch of data, I create an individual frame, in this case one envelope, and send that across our link. It's sent across the link as a sequence of bits and as the receiver received that message they put it into their queue or in their memory and they process one at a time. The processing in our example was they check the parity bit, check the sequence number, convert the binary data into an ASCII character. It depends upon what the protocol is doing, what the communication is doing, but generally we receive, put the data in a queue and then process one at a time. The problem is that we only have a limited amount of memory. The receiving device doesn't have an infinite amount of memory so that if the source sends faster than the receiver can process, you can think it's processing one but more arrive and put in the memory. So eventually the memory will fill up, what happens then? Let's say the memory can store five messages, currently it's full of five messages with processing at receiver and then a sixth message arrives, what happens? Memory is full, another message arrives, what happens, what does a receiver do? Okay, too far advanced. If we don't have flow control, what happens at the receiver? What happens in the first case? If we don't have flow control, you lose the data. Well, either the one that arrives is just discarded, we throw it away because we've got nowhere to put it or maybe another option is one of them in the queue is discarded. In either case the result is we lose some data. It was sent but was not received and that's bad for performance because we're sending data but we don't have the ability to successfully receive it and that's where we lead to flow control and the idea is that somehow the destination will tell the source to slow down. So that picture just tries to illustrate from a computing perspective, we have especially the receiver memory to receive the data, we process the data or a frame, eventually the memory may fill up and therefore we can receive no more data so we need to tell the source to slow down and that is described on those notes. If we don't slow down we'll have a buffer overflow, ignore that picture, let's go direct to, I'll come back to two of those slides, let's go direct to a simple way to do flow control and the name is called stop and wait and it's what we used to communicate, it's very simple. In this picture and I'll describe it after we go through the protocol, A has a lot of data to send to B, so stop and wait protocol defines the rules such that A can send one message, one data message, once they send that A will have to stop, they cannot send any more data, they must wait for an acknowledgement message coming back saying they're allowed to send more and that's, I've tried to illustrate here, A sends a data frame to B, after B has processed that message, B sends back a special message, a frame called an acknowledgement frame saying I acknowledge the data you received, you can now send me more and when I receive or A receives this act frame they can now send the next data frame, they send the next data frame, after sending that data frame they must stop and wait for the act to come back, this is a very simple flow control in that we can only send one message at a time, we cannot send the next message until the receiver says they're ready for it and they'll only send the act when they're actually ready for it and it's similar to what we did, I sent a message then I stop and waited until I received a response back saying I can send the next message, they're ready for the next one, let's stop and wait flow control, any questions how it works, very important one, send data, wait for an act, once you get the act you're allowed to send more data, if you have it, if you don't have data you don't send anything of course, but if you've got a lot of data to send you can only send one at a time before you have to wait for an act, let's now try and describe this picture in a bit more detail by just explaining explaining some parts of what the picture shows, because we'll see these types of diagrams I call, sometimes called message sequence diagrams or timing diagrams to illustrate examples of communications, the vertical lines represent the two devices communicating, A and B, so two computers and the space between them indicates there's a link between them and as we go down the vertical line time is increasing, that's how to visualise this and we use these diagrams to show the transmission of data or the transmission of frames and also the propagation, remember the delay of in a communication system, the delay had four components, transmission, propagation, processing and queuing, in these diagrams we can represent them by showing the space covered on a vertical axis, so delay is just the increase in time, so transmission I show as this rectangle here saying our data frame has some time to transmit, so if we start at this time, start transmitting and the time it takes means it would end at this time, so I draw a rectangle here to indicate this is the transmission time for our data frame, you could calculate that if you knew the data size and the data rate, you can calculate transmission time and put numbers to it, transmission time, as we transmit a signal representing each bit in that data that signal propagates across the link, so I transmit out of my computer a signal, that signal to get to computer B takes some time and that time is called the propagation time, so on this diagram that's illustrated by the difference between when that bit was transmitted at A until when it was received at B, so you see this is the propagation I think it's on the next slide, the time from here to here is the propagation time, we can think of it in detail, A starts transmitting the first bit of that frame here, the signal representing that bit propagates through the link and arrives at this time, so the first bit is received at this time by B, but B must receive the entire frame before it can make use of it, so the second bit would arrive a little bit later, the third bit and eventually the last bit is transmitted here and arrives here at this time B has received the entire frame and can do what they like with it, process, so we use these diagrams to illustrate the timing of sending messages, messages propagating and processing, in simple terms it can be summarized like this, this represents the transmission time and this is the propagation time, processing time we just show by some space here of not transmitting and we'll see some examples of that in a moment, so that's the type of diagram that we're going to use in this lecture and in other lectures, now the stop and wait flow control we describe the general approach, send data, stop and wait for an act to come back, we have two types of frames, the data frame will give each frame type a name, obvious one is the data frame that contains the data we want to get from A to B, so our message or a portion of the message, it also contains some other information, like our envelope was a data frame, inside was the data on the outside, the header contained the source and destination address, sequence number and parity bit, so the data is inside but we also have a header with extra information, we also have an acknowledgement frame which may not contain data, we didn't see that in our case but a message comes back saying you're ready to send more, I'm ready to receive more, so we call that an act frame in short and the rules with stop and wait flow control, the source sends a data frame then they must wait for an act before sending the next data frame, from the destinations perspective when they receive a data frame they can reply with an act if they are ready for more data, if they're still processing they don't send back the act but once they're finished processing and ready for more data they send back the act, so the destination controls how fast the source sends by controlling how fast it sends the act, if the destination is busy, takes a long time to process, they simply don't send the act back until they're ready, we've covered our first flow control protocol, we'll see later the same tech, a similar technique is used for error control as well, with flow control we assume there are no errors at this stage, let's say everything is perfect, the data always gets delivered, any questions about stop and wait, the rules for how it works, so this is just one example, a has data ready to send, when I say data one arrives it means a has some data to send, it creates a frame, transmits the frame, the frame propagates to b, b receives the frame, maybe it has to process, it takes some time to process and then it has some buffer space, some memory available, when it's ready it sends an act frame back to a, transmission of the act, propagation of the act and at this point in time a which has data two already to send, so I'm saying at this point in time data two is ready to send but we're not allowed to send it because we haven't received the act yet, once we receive the act we send data frame two, when it's delivered that is it's received by b, it's processed, send back an act saying you're ready for more and at this point note that during this time nothing is sent by a because a has no more data to send, it's only until here that a has data three to send then it sends data three and my diagram would keep going, so it's incomplete any questions on stop and wait flow control, then I'll give you five minutes to calculate the answer to this, the source a has three 1000 byte messages to send, think it has three frames to send, destination takes one microsecond to process each of the frame once it receives them the data frame has 1000 bytes of data plus a 20 byte header, that 20 bytes may include the addresses the sequence number and other information but we don't know the details we just care about the size in this case an act frame which comes back from b to a contains just 20 bytes no data just 20 bytes of header think of it the link between a and b is two kilometers long the data rate is one megabit per second and the speed of transmission we assume is two by ten to the eight meters per second before you answer what is the throughput what I ask you to do is to calculate that is to draw the diagram like on this slide but while you draw it out keep track of the time remember time increases as we go down so the best way to think about it is that at the start is time zero so if this is time zero what is this time well it depends upon the transmission time you calculate the transmission time all right so then what's this time at b again that depends upon the propagation time so you know that you know the time at b at this point and keep going and find the time for when the act is received and then we'll calculate the throughput once you find the timing so the way to solve this is to draw this diagram but as you draw it keep track of the time as we go think of it as a clock that starts at zero and increases a counter depending upon how long each step takes try and calculate for a few minutes and then we'll go through some steps to to solve that