 And this is in the new set of lecture notes handouts, okay? So we've finished the first set. We're on to the second set now, the second and the final set. So if you don't have it today, you'll get it for next week, okay? You'll survive by just following through today. You may want to take some notes. You'll see in the lecture notes there are several topics that we do not cover. I think there was one before this on digital data communication techniques. There's one after on multiplexing. These are topics that I've left in the lecture notes from, usually from previous years, but I think we will not cover this year just because of time limitations. And in fact, we did not cover last year. So there may be some extra topics that you can browse through in your own time, but will not be assessed or covered in this course. We're moving now on to the second most bottom, the second layer from the bottom, the data link layer. Most of the things we've covered so far about getting data bits, usually, across some link and as a signal. So we've looked at and you looked at in your midterm exam, different ways for encoding our data as some signal and the trade-offs of those different techniques, how do we measure performance and so on. That's about the physical layer. We're now going to spend the rest of the course rather quickly moving up through the remaining four layers, looking at main parts of each of them. And we're going to look now at data link control protocols, which is about the data link layer. And the main purpose of the data link layer is across that physical link, using the physical layer, it gets bits from A to B across one link. The data link layer provides some extra features, some extra services to make sure those bits are delivered correctly and a few other things which we'll see. So still dealing with a link, think of a cable connecting one computer to another. Physical layer gets the bits across there as a signal, data link layer adds some extra features to make sure that data, that sequence of bits is delivered correctly. And generally we have protocols that control the data transfer, data link control protocols. So what are some of the things that data link control protocols do? There's a set listed here, frame synchronization, flow control, error control, addressing control and data, link management. These are some of the features of data link layer protocols. Instead of dealing with just a sequence of bits, which is what the physical layer deals with, as we move up to the higher layers we start to package those bits. And we talk about a set of bits, say as a packet or a frame. So we usually group the bits together. In the data link layer we often call it a frame. So we say we take a thousand bits and that constitutes one frame. And we deal with on a frame by frame basis as opposed bit by bit basis. Some of the issues that the data link layer has to deal with is how do we know what is the start of a frame and what is the end of a frame? How do we define a frame? How long is it? How does the receiver know when an old frame finishes and a new frame starts, frame synchronization? We'll see some examples of frames visually as we go through some protocols. Flow control is what we're going to cover in this topic. So we'll explain that in a moment, so in detail flow control. Addressing, when we send data from one computer to another, usually they have a hardware address, a MAC address is another name. So allocating addresses, defining the structure of addresses is part of the data link layer. Some of you, when you use the internet, you know that you have an IP address, an internet address. But if you also look at the details of your mobile phone, your laptop, your PC, you'll see that there's an address associated with your LAN card or your wireless LAN card, a MAC address sometimes or hardware address. That address is part of the data link layer. So it's the data link layer that's responsible for making sure that the devices have correct addresses. Another example, often before we transfer data from A to B across a link, we set up that link. A says to B, I want to transfer data to you, are you ready to receive data? And if B responds, yes, I'm ready to receive and then they start the data transfer. The concept of link management, setting up a link, making sure that link is maintained while we want to transfer that data. Error control, with the physical layer, we send a signal which represents bits across our link. There may be some errors because of interference, noise. The bits received may be different from the bits transmitted. They have bit errors at the receiver. So we want to deal with them. And one part of the data link layer is to perform error control, which is to first detect if the receiver has received something in error, detect errors, and then preferably also correct those errors. So if I transmit a sequence of bits 0, 1, 1, 0, and the receiver receives 0, 1, 1, 1, there's a bit error there. One thing to do would be to ask the sender to send again to retransmit that data so that hopefully the second time it would be received without an error. And that's one form of error control. And we're going to discuss that in this topic as well. Error control and flow control. Flow control we're going to go into today. We'll get finished on part of it and then we'll move on to error control after that. But there are other parts that we will not get to cover in this course about the data link layer. Flow control is rather simple, the concept. It's about making sure that the sender doesn't overflow the receiver. That is, the sender doesn't send the data too fast such that the receiver memory or buffer overflows. So we're going to talk about that and use this picture to show that. Let's show an example. We need a volunteer. See who wants to volunteer. Okay, thank you. Come up in the front as my receiver. I'm going to be the transmitter. I've got data to send to my receiver. Sorry. I've got one. I'll get you for the next volunteer. I'll just stand here. I'm going to send data to... So imagine I'm the transmitting computer. He's the receiving computer. I'm going to send some data to him. And you see the data... Instead of sending bits, we talk about a group of bits, say a frame or a packet. So my data in this case is a set of lids. They have a number on them. You'll see on the front there's a number, zero. You just wait. There's a data or a frame. So let's say inside here there are, say, a thousand bits. So my idea, my aim is to get all of this data to him. He's the receiver. He's going to process the data. Whatever the data is, whether it's an image, he's going to combine the bits together and show the image on the screen. To demonstrate, I'm going to pass each frame to you. And the processing that you're going to do is when you receive one, you'll look on the front, look at the number, and write the number on the board. So get your pen ready. Let's get ready. In fact, the numbers... I'll just show him so it's a bit easier. Normally we'd expect the numbers to be in order, but to make life simpler for me and the receiver, I'm just going to send them out of order. So look when you receive. When you receive, not yet. Just look at the number on the front and write it down. Not yet. You need to catch them. Okay. Ready? Okay. Come on. I overflowed the receiver in this case. So this is the concept of why we need... Okay. Fine. I think you see what happened there is that I'm the transmitter. You can take a seat. Thank you. Well done. I'm the transmitter sending data to the receiver. The receiver receives the data, processes, and then receives the next data. But what happened is I sent the data too fast because he could only process what he received at some rate. It took him a few seconds to catch and write on the board. So that was the processing rate of the receiver. And because he was processing one frame of data, and I was transmitting the next one and the next one, I could transmit as fast as I like, and what happened eventually was that he was processing one and the next one arrived and he had no capability to receive that. He dropped that. I overflowed the receiver in that case. Now, in a computer, this overflowing at the receiver is because of the limited memory at the receiver. So for the person, the reason he dropped some of the lids was because he had limited catching capability. He only had one hand to catch and to write and he couldn't catch multiple at the same time. When the receiver, when we're sending data to a receiver, that receiver receives the data and puts it in memory. Sometimes we call it a buffer or a queue but inside the computer memory. And because the computer memory is fixed, there's a limited amount of memory available, if we receive a lot of data, store it in memory and it takes a long time to process that data, if the sender keeps sending data, once the memory is full and new data arrives, what happens? If there's no more space in memory to store the data, then something's going to be dropped. Not dropped on the floor but in terms of if our memory is full and we receive new data, we cannot put it anywhere, we cannot put it in memory so the receiver must discard that data. We don't receive the data, which is a problem. We'd like the receiver to be able to receive everything that's sent. So that's the concept of overflowing the receiver. Flow control is about making sure we don't overflow the receiver. Let's see if we can implement it. Let's have another volunteer. I'm going to transmit again and you're going to do the same thing, receive right down the number. And let's try and implement some flow control. In this case, when you receive one frame, you'll tell me when you're ready to receive the next one. I won't throw, that's a bit mean. So normally I would just keep sending. Write the number down. I'm ready to send more, but I will not send more until he says he's ready to receive. And you see that this will work in that the receiver is controlling how fast I send. And I think we'll see that if the receiver controls how fast I send, then I should not overflow the receiver. Okay, thank you. So flow control in a very simple manner is the receiver says when they're ready to receive more. Without flow control, what can happen is that the sender sends too fast, the receiver becomes overflowed and starts to lose data, starts to drop frames. With flow control, the receiver tells the sender slow down or just send me at this slow rate so I can process and move forward. So we're going to look at two basic mechanisms for implementing this way for the receiver to tell the sender when to send. This diagram on the screen tries to show from the, this is the sender computer and this is the receiver computer. And looking at the details just from the data link layer, typically receivers have some finite amount of memory to store the data they receive. So I've drawn that as this, let's say, queue or buffer here. Let's say we have a memory of this receiver of 10,000 bytes, which means that once I've stored 10,000 bytes in memory, if I receive something else, I cannot put that anywhere and I'll lose that data. And what happens is that the source has some data to send. It transmits the first frame across the link and then we'll transmit the second frame as long as it has data to send. We'll keep transmitting frames containing the data across the link. And as the frames arrive, the receiver puts them in memory. So they receive them. They process them, say, right on the board. They do what they need to do with the data and pass it up to whoever's going to use it. If we look at a layered perspective, look, pass it up to the network. So that receiving processing takes some time. Even for a computer, it may take, depending on the speed of the receiver, it may take microseconds, milliseconds, depending on what's happening. So if we're sending fast here and we're processing slowly, what happens is that more frames arrive than can be processed in some period of time and they start to be put into memory in the buffer and because the buffer has a limited size, eventually it becomes full. When it's full, this one's processing a frame. This buffer is full. The next frame arrives. Well, what can happen? Something has to be discarded. That is, if the frame arrives, either it's not stored in memory, it's dropped or discarded, or maybe one of the ones already in memory is discarded. But the end result is some of that data is lost. It's not successfully received or passed up to the network layer into the eventual destination application. So that's bad. We don't want to send data and have it not received. And hence we have flow control, which is as the receiver receives data, it sends back some feedback to the source saying, giving an indicator of how much more it can receive. So controlling how fast the source sends. We saw with a quick example that one way is that I send one data frame. When the receiver has processed that one data frame, he sends back some acknowledgement saying, thank you, I've received it, please send me another data frame. So we send that other data frame, and then I cannot send a new one until he sends back an acknowledgement saying, thank you, please send another one. So that's a flow control protocol. It's the receiver controlling how fast the source sends. We'll go through that protocol in a bit more depth. So in summary, receivers have a fixed amount of memory to receive the data. If we send too fast, we can overflow that memory, losing data. That's bad. Therefore, flow control protocols allow the receiver to effectively inform the source how much more space it has available in the memory to receive new data. So that's not overflow. That's the concept at least. Everyone's experts now. No problems. You understand what you did in the example. You understand how you will improve next time in receiving the data. What will you do? You dropped many packets. How would you improve that next time? Okay, you would tell me, thank you, I've received it now. Now I want the next one. That's the idea is that the receiver would say, thank you, I've received your data, I've processed it, now send me the next one. That's one way at least. So, flow control. Aim to ensure the sender does not overflow or overwhelm the receiver. If the sender sends too fast, then the buffer, the memory at the receiver can overflow. It becomes full and we cannot store anything else. The result is buffer overflow at the receiver. Data is lost. Losing data is bad because it becomes inefficient in the data transfer. So we possibly need to retransmit and we'll see later if we need to retransmit we'll reduce the performance of the system. So we want to avoid data loss. Hence we implement some flow control mechanism which tries to prevent this buffer overflow, prevent any loss of data. And we're going to look at two mechanisms for implementing flow control. In the following slides, when we look at flow control we're going to assume that when we transmit data across a link there's no packet loss or there's no data loss. That is, there's no noise or interference that cause the bits to be lost across the link. Just to keep things simple. We'll see that maybe the delay may vary. We'll see the impact of that later. We're looking at the data link layer. Above the data link layer we have the network layer and then the transport layer. It turns out that flow control mechanisms are also used in the transport layer. In particular in TCP. So even though we're talking about the data link layer the same mechanisms are used in other protocols and therefore they're very important to understand. They have a large impact on their performance of internet applications. So let's today go through a flow control protocol but to do that we need to introduce a new way to draw some pictures. I like to draw pictures to show how a protocol works. I'm going to first explain the type of picture I'm going to use. So these next two or three slides are about one technique to analyse and illustrate protocols. Not just flow control protocols but others. First remember that in a very simple link if we have computer A connected to computer B via some cable inside each computer we can break into the different layers. And the way we can think the data flows is that some user at computer A creates some data an image for example that they want to send to computer B. The application passes that down to the transport layer and it's processed. Maybe attach some header. And then we do that through all the layers. We do some processing on the data according to the protocol pass it down and eventually send the bits across the link. And as those bits are received the opposite is performed at the receiver. We process, pass it up and eventually the original data is passed up to the user at computer B. That's the data flow through the layered stack. Now coming back to delay how long does it take to get the data from A to B? Well we've studied that in one of our first our second topic of what are the four components of delay? Well they're processing, queuing, transmission and propagation. We can think that inside each layer which are implemented inside our computers there may be some processing delay and possibly some queuing delay. In this course we don't have a way to calculate them I usually give them to you I say okay this computer has a processing delay of one microsecond. It's usually small because computers nowadays are fast to process a thousand bytes of data using the CPU and the memory it doesn't take very long but it takes a small amount of time. In some cases there may be an additional queuing delay. So normally we can think that there's processing and queuing delay in each of the layers. Transport layer processes, network layer processes there may be some delay in each of them. So those delays are inside the computers both the source and destination. The other two components of delay are transmission and propagation. Transmission think of as how long does it take for the physical layer to send the bits onto the link and we can calculate that. Remember transmission you did it in your midterm we take the data size, the number of bits divided by the data rate. So a thousand bytes is if that's the amount of data we need to send and we're sending it one megabit per second we can determine the transmission delay. That's the time to transmit the bits onto the link. Propagation delay is the time for one of those bits or the signal representing one of those bits to propagate across this link. And it depends upon the physical characteristics the distance of the link in meters and the speed at which the signal propagates the speed of light for example. So we can calculate them the others usually are given to us at least in this course. Add them all up and we get the total delay from A to B. Now that's known that's what you know already. If we focus just on the data link layer that is let's see what happens with the data link layer. We receive data, we transmit to the physical layer and then we receive here we can break it into these eight steps. We receive data from the higher layer step one. We may have to queue the data there may be some queuing delay maybe it's zero, maybe it's there's some delay there. We process the data we do some processing it takes some time then we transmit that data by sending it by the physical layer. Now the data will call a frame in this case so we say we transmit a frame a frame is just a collection of bits instead of dealing just with individual bits we group them together. So we transmit a frame of bits that takes some time that transmission time it's the frame size divided by the data rate the data rate of our link that frame propagates across the link it's arrived it's processed by the receiver it's possibly queued at the receiver and then sent to the next higher layer so from the perspective of the data link layer those are eight steps there. Now let's get to what we're aiming for. This is one way in which we commonly draw diagrams to illustrate what's happening in a protocol and also to do some calculations it's called a sometimes called a time sequence diagram or a message sequence diagram it's a type of diagram to illustrate the operation of a protocol let's go through the parts so here are the two computers A and B these vertical lines for A and B will show on those lines things that happen at computer A and computer B and because those things that happen at A and B take time will illustrate time as increasing as we go down in this diagram so if we say time starts at time zero something takes some time so time is increasing as we go down what we'd like to do is illustrate the time it takes to get data from A to B showing those four components queuing, processing, transmission and propagation this example shows I think or it shows just two of those components transmission and propagation let's say at this point in time at computer A data arrives from the network layer that's step one there may be some queuing delay there may be some processing delay in this example this is just one example I haven't drawn any queuing or processing delay I assume they're small, zero just for this example later examples which are more complex that is the data arrives and then we transmit that data and the time to transmit that data depends upon the data size the frame size and the data rate and to illustrate that it takes time to transmit this frame I've drawn this rectangle here think of this rectangle meaning the frame of data and it takes time so I start transmitting I'm transmitting, I'm transmitting over time and then at this time I end transmitting so these rectangles are used to illustrate a transmission of a frame we can use it in both directions as we transmit a signal from A through to B it takes time to propagate so if we think we start transmitting at this time the signal starts propagating across our link and I've drawn that propagation as this arrow this line going from A to B it starts propagating here takes some time and eventually arrives at B the time it takes from when it leaves A to reach B is the propagation delay so if we start transmitting at this time with some propagation delay we receive that first bit of the frame at this time we finish transmitting the last bit at this time at A again that bit needs to propagate across the link it takes time and eventually arrives at B so from B's perspective it starts receiving the frame here it's receiving, receiving and receives the last bit of the frame and hence has received the frame in its entirety at this time processes the data and passes it up so delivers the data to the network what we'll do is in this topic and even in other topics we commonly use these diagrams to show what's happening the timing of sending the messages and receiving responses and in fact we'll also use them to calculate, to simplify the calculations of the total time it takes the throughput and the efficiency so this is just introducing the diagram structure and now we're going to look at flow control and we'll see how this is used so we'll see some examples in this example, next slide we can say the time from here to here is the transmission time and from here to here is the propagation time let's move on and look at flow control and see an example of this diagram back to our demo first student I threw the packets to and I threw them too fast and he started to drop them the second one I sent a frame of data and the protocol was that when he received and processed that frame of data he then sent back a response saying I'm ready for the next one and my step was I send one I don't send another one until I receive the response this is a flow control protocol called stop and wait flow control I transmit a frame I stop and wait for a response before I transmit the next frame so that's a very simple flow control protocol we have two types of frames I transmit a data frame to the receiver I'm trying to send data to the receiver the receiver sends back a different frame to me saying I'm ready for the next one sends back an acknowledgement frame or simply an act frame so the data frame contains the information we're trying to deliver the one that comes back we'll call it an act frame or acknowledgement frame there are other names the receipt of that data and it tells me I'm allowed to send the next one remember a protocol is just a set of rules that define what the entities do to communicate so the rules in the stop and wait flow control protocol are source transmits a data frame then the source waits for an act frame before sending the next data frame so I'm not allowed to send the next one until I receive an act that's the rule I cannot send two data frames in a row must be send data receive act then send the next data receive the next act that's the source what does the destination do when a destination receives a data frame it processes that data it's not shown here but it processes that data when it's ready to receive more it replies with an act so the destination receives the data looks at it processes it done with the data and now sends back an act saying I'm ready to receive more data and if the destination is busy so the destination has received some data is taking a long time to process it then to make sure that the source doesn't send anymore simply don't send an act delay the sending of an act so that's the flow control mechanism because the source is not allowed to send more data until it receives an act the destination controls the speed at which the source sends by controlling when it sends an act an acknowledgement the normal result is what we get is send data act comes back send the next piece of data and we just keep going like that if everything works fine data act so that's the stop and wait flow control protocol it's illustrated as an example in this diagram and I've taken let's say we have a lot of data to send from A to B and instead of sending all in one frame we divide that data into multiple frames we'll discuss later why we'd do that and the advantages and disadvantages but let's say for example I have a million bytes of data to send from A to B so what I do is I send a thousand bytes at a time each frame contains a thousand bytes of data so frame one the first one thousand bytes arrives from the higher layer I have a thousand bytes to send I put it inside a frame computer A transmits that frame to B the time it takes to transmit is shown by this rectangle it takes some time we start transmitting we finish transmitting and the signal takes time to propagate across the link the time in which the receiver B has received that frame is at this time here the end of the arrow because we need to transmit the entire frame and B needs to receive the entire frame so it depends upon the transmission time and the propagation time B receives the frame and now processes that frame it takes time to process it may not be ready to receive more in this example I said B receives the frame it's processing it's got stored in the buffer in the memory there's no more space to receive a new one yet so it doesn't send an act yet it waits until the data has been processed and delivered to the higher layer and now there's more space in the buffer to receive the next frame and if we're allowed to receive the next frame what we do is compute A by sending an act an acknowledgement frame so it takes time to transmit this act frame it's of some size it takes time to propagate back to A and at that time A has received the act and A now knows it's allowed to send the next data now coming back to what happened to A it had data, data 1 to send at the start it transmits in the first frame and after transmitting that frame A has no more data to send so it does nothing it's just waiting it's waiting, it's waiting but then some more data arrives from its higher layer ready to be sent to B that is data 2 the second 1000 bytes arrive and A needs to send this second piece of data to B but at this point in time it's not allowed to although it's got data to send to B A is not doing anything it transmitted a frame now it's just doing nothing it's not allowed to send the second frame because it hasn't yet received an act for the previous frame when it does receive the next act then it can send the second frame containing this data and that's data frame 2 is transmitted takes some time to transmit to propagate to B in this example I say that B receives the data and immediately processes it and immediately sends back an act saying I'm ready for the next one so it sends back an act coming back to A we transmitted the data frame containing data 2 we're waiting for an act we're not doing anything we don't have any more data to send yet we receive the act which allows us to send more data if we've sent one data frame we receive the act that means yes you can send the next one but since we don't have any more data to send we don't send anything but then if we have more data to send of course we can send data frame 3 and the diagram doesn't show it but we'd propagate eventually we'd receive an act back and then we could move on to the next data frame and if we had a thousand chunks of data to send if everything worked well we'd see this pattern of data act, data, act data, act and continue until all the data is delivered the receiver should never be overflowed in this case so long as the receiver has space to receive one frame because the receiver be only ever receives one frame at a time receives the first frame puts it into memory once it's processed and removed from memory it sends an act saying I'm ready for the next one and sends when be receives the next frame it stores that in memory once it processes that data puts it from memory and making space available in the memory and sends back an act saying I'm ready for the next one so there's no chance for A to overflow the receiver in this case which is the aim of our flow control protocol any questions on how this works stop and wait concepts are simple some of the technical details may be new to you we'll go through another example soon the protocol rules send a data frame wait for an act before you can send the next one and the receiver when we've received a data frame process it and when you're ready for the next one send an act and we get this the source sends it stops and waits and then it sends and it stops and waits and then sends and continues to do that so if you understand the the rules for stop and wait then you can answer this question try and the way to answer it is to use your basic knowledge of transmission and propagation delay and draw a diagram that illustrates the exchange of these 3 messages so in this simple case the source has 3 1000 byte messages to be sent it has them already to send to be 3000 bytes to send we'll come back to the processing when we send the data so we have 3000 bytes of data when we send it in a frame in our data frame we put 1000 bytes at a time in each frame so 1 frame contains 1000 bytes of data a frame also contains a header most protocols add a header to include extra information to support protocol I'm just making up some numbers for this question I say that the data frame contains 1000 bytes of data plus a 20 byte header so the frame is in fact 1020 bytes in length an act frame contains no data it just contains the header in this case the act frame is 20 bytes in length so we know the size of the two frames we have some information about the link 2 kilometers data rate of 1 megabit per second velocity so instead of the speed of light to keep things simple 2 by 10 to the 8 meters per second so you can calculate propagation delay you can calculate frame transmission delay I tell you that there's a processing delay at the destination of 1 microsecond there's no other processing or queuing delays to keep things simple before you answer what is the throughput now try and draw a diagram which is similar to this which is easy but now try to start to put numbers to the time that is assume we start at time 0 so this would be time 0 here if you know how long it takes to transmit the data frame if we start at time 0 then the time here would be the transmission time and the time at this point would be the transmission time plus the propagation time and try and label this diagram with the times at each of these steps what is this time what is this time and so on doing that we can help you to calculate the total time and then we'll use that to calculate the throughput so the idea is to draw this diagram but put numbers on it as well showing the time to do each step to put those numbers on it you need to know we'll do some calculations first so calculate the propagation and transmission delay first thing you can calculate is the transmission delay of the data if you know the data size you know the data rate you can calculate the transmission delay we'll need that later I haven't shown the units but our data frame the data frame contains 1000 bytes of data plus 20 bytes of header so we have 1020 bytes in total we send that at a data rate of 1 megabit per second so the transmission delay is simply the data size divided by the data rate I'll note that is transmission and lowercase d for the subscript d for the data frame what's the answer 1020 bytes times by 8 is 8160 bits divided by 1 megabit per second 816o microseconds you can use other prefix you can use millisecond seconds just to keep things consistent and simple so the transmission delay of 1 data frame containing 1000 bytes of data is 8160 microseconds in the following in what I write here I may not give time units if I don't give time units then assume it's in microseconds so I'll keep everything in microseconds so that it's easier to add them up later similar we'll also know the transmission delay of the AC frame the transmission delay of the AC the AC is simply 20 bytes so we do the same approach the same data rate you'll get it's 160 microseconds so that's basic calculations the other thing that we'll need is the propagation delay and if you look at the question we'll see that the propagation delay is the same in both directions because the link is the same distance the transmission speed in both directions we had 2000 2000 meters is that right? 2 kilometers and we had 2 by 10 to the 8 meters per second that equals 10 microseconds this 160 is also microseconds we need those numbers when we go through and look at all the time steps so the stuff that you did early in the semester transmission and propagation delay transmission of the data frame 816o microseconds transmission delay of the AC frame 160 microseconds propagation delay in both directions so in one direction 10 microseconds in the other direction also 10 microseconds now start drawing this diagram for our scenario but label the time think of you have a clock the clock starts at 0 so this point here is time 0 then what is this point on our clock well if we start at time 0 this illustrate the rectangle illustrates the transmission time of a data frame if we start at time 0 this point would be 816o microseconds because it takes 816o microseconds to transmit that frame so what you should do is label here 816o and I suggest you keep everything in microseconds it will be easier so 0, 816o and then well what is this time if we finish transmitting at time 816o at what time has the entire frame arrived at B well you need to take out the propagation delay try and follow through the diagram labelling the time the clock value try and draw the diagram yourself to get started I always say include units make sure you include units in your answers for simplicity on these diagrams as long as you define the units you may omit them to keep it a bit simpler in my case I suggest well in my case I'll use microseconds I suggest you do the same so you don't have to write microseconds just use the number so now start drawing the diagram and label 0, 816o what is this time and then find now label from the perspective of a clock if this is time 0 what is this time it would be this rectangle represents the transmission time ok now keep going good let's start drawing to give you a hint what I'm suggesting to do to help in the final calculation so A this is our time sequence diagram A and B the rectangle I draw here illustrates the transmission of a frame which takes some time so and the green numbers indicate the clock value let's say our clock starts at 0 we start timing everything starts at time 0 indicating the data frame how long does it take graphically it's shown as this time start transmitting here finish transmitting here therefore if we start our clock at 0 this time point is 816o microseconds because we calculated before the transmission delay to be 816o now while we're transmitting that in fact the bits are propagating across the link so you need to determine when does that data frame start to arrive and finally completely arrive at B so keep drawing the diagram and label the clock value to see the timing now you don't have to draw to this level of detail we'll say that we can simplify it in a moment but to show the detail remember we start transmitting the frame here the frame is made up of a sequence of bits we have 8160 bits what you can think of is we transmit one bit at a frame one bit at a time where we're sending at a rate of 1 million bits per second so A transmits the first bit it comes out of the computer goes across the link starts to go across the link then transmits the second bit the third bit that comes out of the computer when it's finished transmitting the frame we're at time 8160 so this illustrates the transmission time now the other thing is that as we each bit comes out of the computer the signal needs to propagate across the link and that takes time the propagation time and the way I've illustrated it here is that if I transmit the first bit at time 0 the first bit comes out of my computer at time 0 then it takes 10 microseconds to propagate across the link from A to B therefore that first bit will arrive at B at time 10 on our clock the second bit will arrive a little bit later and the third bit after that because we transmitted one at a time they arrive one at a time destination B if I transmit that last bit at time 8160 it takes 10 microseconds to propagate across the link that last bit arrives at time 8170 at B 10 microseconds later so from B's perspective it starts receiving the frame at time 10 and it's received the frame and it's entirety at time 8170 it's received it in full and we mainly care about when we receive it in full because only then can we process that data what does B do next before it transmits the act B has received the data at this point in time I've just received the frame and in the question we see that the destination takes one microsecond to process add a little bit more it takes some time to process that as we receive the frame put it in memory process the frame when we finish processing we remove it from memory and then send the act so we don't send the act immediately we have a small processing delay and then send the act you'll see my diagram won't be to scale but we'll try and capture most things I don't have space to draw all the components or to draw it to scale but let's see what happens B received the first bit of the frame at time 10 received last bit at time 8170 it's here it's now received the entire frame what it does now is it processes that frame and in the question we said the processing time takes one microsecond so although I haven't written it if this was time 8170 on our clock this time here when we finish the processing would be 8171 plus one 8171 once we've finished processing we're ready for the next one the next data to indicate to A we're ready we send back an act an acknowledgement frame and I've drawn the act frame here if we start transmitting the act frame at 8171 we calculated before the transmission delay of the act frame was 160 therefore we'd finish transmitting the act frame at 8171 plus 160 is 8331 that's when we've finished transmitting the act frame the same as the data frame the act has to propagate so the first bit arrives and eventually the entire act arrives at what time it's quite simple if we finish transmitting at 8331 and it takes 10 to propagate it will arrive at 8341 keeping track of this clock as we go is going to be useful in determining the total time and then the throughput we've got two more packets to send we'll see similar to the first case any questions on this first data frame how I come up with those numbers remember we're using stop and wait flow controls send the data stop and wait for an act to come back so A sends the first data frame the question said that we have 3000 bytes to send the first frame contains just 1000 bytes so we have 2000 left to send but A is not allowed to send the next data frame until it receives the act back and what B does receives the data when it receives data processes removes from memory makes space available in the buffer to receive more and sends an act saying I'm ready to receive one more send the act back and when A receives the act in its entirety we use B has received the data B is ready for more so A sends more A transmits another data frame and you continue through for the timing and the hint is it will look exactly the same as here because nothing changes in the next data frame every data frame propagate process act propagate back and keep adding on to our clock see if you can do that we have three data frames we have 3000 bytes so in fact this repeated two more times find the total time down the bottom the time when we finish so A341 we're allowed to send the next data frame so let's send it and follow through the steps the data frame takes time to transmit the last bit we'll arrive at this point in time then we'll process so there'll be a small delay here and then we are ready to send the act back and the act needs to propagate back and we'll arrive at this time you can determine the number the clock in each of these points we start at A341 plus the transmission time plus the 10 to propagate plus the 1 to process plus the 1 to process 160 for the act to be transmitted plus 10 to come back and you'll arrive at the time here anyone have the value 16682 sounds right and then when the act comes back A will be able to send the next data frame and we'll get the same steps and if you go through those calculations at the time you should see at this point the finishing the second frame is 16 682 and then we go through again data, propagate, process act propagate and I've calculated before anyone get an answer 2500 2500 0013 0013 0023 I think you'll find the last time it's 25023 you can draw it better than me and you should label data acts so you know what these things mean and in fact you should just to be sure label the clock values at each of the points it's just adding on numbers and you should arrive at that final time of 25023 and if you look closely you'll see the second two packets frame two and frame three we had three data frames we get exactly the same as frame one the frames are the same size propagation delay is the same so in this example the time from look for the first data frame data propagation processing act propagation took 8341 microseconds from 0 to 8341 and in fact in the second data frame between this time and here is also 8341 because everything's the same and in the third one from here to here is also 8341 for each data frame to get the data frame there and the act back it takes 8341 microseconds and you'll see that the final answer this 25023 is simply three times 8341 of course my diagram's not to scale processing delay is much smaller relative to the other the reason for including the clock value in this diagram is it will help us calculate the throughput because now we know the total time to deliver the data let's say we had not three frames but three million frames of data to send everything the same and I ask you to keep drawing it for three million frames then you need to calculate what's the time at the end well again you'll see that okay for the first frame it takes 8341 each subsequent frame is exactly the same another 8341 microseconds because it's the same same link same data size so the total time you wouldn't draw of course but you could calculate the total time it's just 8341 for each frame so if we have 3 million it's 3 million times 8341 so you can extend it to any number of data frames now the question and what we're trying to arrive at is the throughput how fast is the receiver receiving real data and from the receiver's perspective how often do we receive a data frame from bee's perspective how often if we continue this 3 million frames what could we say about the rate at which we receive data frames how often do we receive a data frame from bee's perspective every something microseconds that's what I'm looking for how often if we look not just at the first one but the second one and the third one and even if we had others how often does bee receive a data frame if we can see it on the diagram bee started receiving the first one at this time it started receiving the frame and then it started receiving the second frame although it's not clear on the diagram but around here that is at this time bee started to receive frame one received the entire frame one and then if we followed frame two it would start to receive at this time because the frame is transmitted here arrives here and similar it would start to receive frame three at this time and if we had more frames I don't have it on the diagram the fourth frame if there was one we would check it's about here if we look and see the pattern from bee's objective it's receiving a frame it receives a frame then it waits sends an act and then receive an X frame and continues doing that we can say that it receives one frame in every period of every time of this duration what is this duration you can go back and calculate but you'll see well it's the same as the time to deliver one frame it's 8341 microseconds bee is receiving a data frame every 8341 microseconds and you can check that by doing the calculations I won't in 8341 microseconds it receives the first frame plus there's the time of waiting and sending back an act and in the next 8341 microseconds it receives another frame and then in the next 8341 microseconds another frame and if we had continuous data frames to send it would keep going almost out of time but let's finish this the end result for our throughput if we're receiving one data frame one data frame every 8341 microseconds one data frame contains 1,000 bytes of real data plus 20 bytes of header so we're receiving 1,000 bytes of real data every 8341 microseconds that's the rate at which we receive real data which is the throughput by definition and the calculation turns out to be around 959 118 bits per second that is the throughput using this protocol it's the rate at which we receive the real data one data frame every 8341 microseconds each data frame contains 1,000 bytes of data plus 20 bytes of header and therefore if we divide them we get around 959 kilobits per second we had a 1 megabit per second or 1 million bit per second data rate the throughput is 959,118 bits per second less, slightly less than the data rate out of time for today check those calculations for yourself make sure you can determine those numbers the total time that I come up with 25023 and make sure you can calculate the throughput I went through that quickly at the end check and see if you do consider it the throughput is the rate at which we receive the real data this contains the act look, the hardest thing here and maybe we'll have to go through next week again but see if you can work out why is the 8341 here think about maybe keep drawing more packets and look at the pattern the rate at which the receives data and see why it's 8341 if you can get through that concept I think you can be clear on this and that can apply this to other situations the 8341 is the time to receive the frame process, transmit the act and then wait for the next frame to arrive let's stop there and next week we'll look at some variations of this example and then look at a better or a different flow control protocol is there a quiz this week good question I haven't created one yet, I'll think about it