Understanding Reliable Data Transfer Protocols

bismillahirrahmanirrahim assalamualaikum class welcome to data communication and computer networks course data communication and computer networks previous week lectures chapter number three is about transport layer basically transport layer functions transport layer is used to transfer data from one process to another as we know that network layer is used to transport data from one host to another. Then we saw how the network layer enhances its functionality by doing multiplexing and demultiplexing. After that we discussed what are connectionless protocols or connectionless data transfer. We also discussed the rules of UDP protocol. What facilities does it provide and how does UDP perform error detection by using checksum? So, our topic for this week is about principles of reliable data transfer. When we discuss topics in this chapter, the generic pattern that we see is that generic data transfer is a process of What is the perspective of a topic? Let's suppose we are saying what is reliable data transfer in general? Then we will discuss how the CCP implements the facility of reliable data transfer. So in this topic we are generically discussing what is reliable data transfer basically? How do we design a protocol in which we ensure that our data from one point to another will be reliably transferred over an unreliable channel? So let's say we have a data transfer in a particular country. Because if we talk about real life, we send data on a highly unreliable channel in which all kinds of interference can be encountered. So, on that highly unreliable channel, how can you design a protocol on the transport layer which can reliably transfer your data over an unreliable channel to the destination. So, this is our main purpose of this topic which is known as principles of reliable data transfer. So, let's start. If we talk about principles of reliable data transfer, the top 10 trending topics in the computer network so far, we have reliable data transfer in the top 10. Because it is very important. At the same time, if we talk about which layer is important for reliable data transfer, it is not only important for the transport layer, it is as important for the data link layer as well. So, we say that the reliable data transfer is important for multiple layers, so it is a trending topic. So, when we talk about reliable data transfer, we have the application layer, that layer where processes are being run and data is being generated. So, as soon as data is generated, it is sent to the transport layer. We have already discussed the work of the transport layer, that it has to divide data into chunks, add headers and then network layer network layer comes to data link layer data link layer comes to physical layer and physical layer forwards it to the destination now we have provided model if I see its service implementation then what will be the service implementation The application layer generates the data and calls the RDT send function. Now we have come to the protocol designing. How will the reliable data transfer protocol work? So, first of all, we have the application layer that generates the data, called the RDT send function, the RDT send function will take the data from the application layer and will bring it to the transport layer here. Now we have to design a protocol on the transport layer which is known as the reliable data transfer protocol. RDT means Reliable Data Transfer Send function So, the function of Reliable Data Send is called and the data is fetched on the transport layer Now, what we have to do with the Reliable Data Transfer Protocol is We have to divide the data in chunks, add the header, and add the reliability features And then, using the UDT send function, this data force and the reliability features on the data, and then send the data over an unreliable channel. So, note that when the data was coming, we were calling it data, but when the reliable data transfer protocol is sending the data, we are calling that data packet. Now we have sent this packet on unreliable channel. When this packet will reach receiving side, there is a protocol receiver, which is a function of reliable data transfer, which is known as RDT receive. That function has to receive that packet. It has to check that this data is received correctly, there is no error in it or whatever. This is the work of reliable data transfer protocol. It has to retrieve and extract that data. If that data is correct, it will deliver that data to the application layer. Now, this work of reliability checking or error detection or error recovery, this work has to be done by reliable data transfer protocol. If we talk about the previous topic of connectionless UDP, then we discussed that checksum is a technique that is used to detect errors. it is not a technique that helps you to recover from error UDT does not give you the procedure of recovery UDT says that if your data is detected that it is error prone data then you have to either discard that data or you have to send the same data which contains error to the application layer with a warning that this data may contain error So, you forwarded the application layer with warning. Now, UDT does not decide how to recover from that error. This feature is not present in UDT. UDT has a feature of detection and not a feature of recovery. So, characteristics of an unreliable channel will determine the complexity of the reliable data transfer protocol. This thing, if you don't get this right now, In the future, when we discuss our next slide, this will be more clear to you. Here it is discussed that how complex your protocol will be. It is conditional on this thing. You can say that it is connected to this thing that how unreliable is your channel. If that channel is more unreliable, that means that error is also and there is packet loss, then the protocol you have to make will be very complex. But if you have a channel on which you know that the packet can only be flipped and not loose, then your protocol designing will be a little easier. This means that the more your underlying channel is unreliable, the more the complexity of your protocol will increase. If you still do not understand this, then we will discuss it in the future. Now we will discuss the topic of... Now, we have seen the previous service model implementation, in which the RDT send function we have already briefly discussed what it is, but once again I am present in the slides that how the RDT send function is called. RDT underscore send, reliable data transfer underscore send function is called from above, that is from application layer, which is used so that data can be passed on to the gate. the transport layer. Now, RDT send calls this function on the sending side and then UDT send function calls the transport layer so that this function is called by RDT so that UDT underscore send function is called so that your packet and transfer it over an unreliable channel so that it can reach the receiver. Now on the receiving side, there is a function called RDT underscore receive which is called when a packet comes on the receiving side. Now the function of the delivered data is called by RDT, the protocol of reliable data transfer so that the data extracted from the packet, that data is transferred to the upper layer of the application. So if we have an application layer from the upper layer of the application, then that data is transferred to it. transfer. So this is how service implementation should be. Now we are moving towards the steps of our reliable data transfer protocol. So we will develop our reliable data transfer protocols incrementally so that you have a clear idea of how the protocol is designed. First of all, The point that was put here is that the sender side or the receiver side has to develop the protocol incrementally from both sides. It is not that we start discussing a very complex protocol all the way and you don't understand what that protocol is. We will discuss the protocol gradually as to what protocol designing is. So, for protocol designing, we have taken some assumptions. We are saying that consider only Unidirectional Data Transfer Why we are talking about unidirectional data transfer? Because we are sending data to sender and receiver Obviously if it is requested for data then it will reply But in this scenario of Reliable Data Transfer Protocol In this we are talking about unidirectional data transfer And we are talking about unidirectional data transfer only for data Not for the control information Now what is the difference between data and control information? That we have that information or file, text file, image file, audio file, video file, so I have this data transfer. But if that video file is received, then it is getting an OK message or if it is not received, then I am getting a not OK message. So this is called control information. So the point I want to tell here is that your data transfer is unidirectional. Control information will come from both sides. If you send data from here, then if you want to buy that data, If you receive the message correctly, you will receive an OK message. That is two-way communication. The receiver will send the control information back, but not the data. We have to keep this assumption in mind. Use finite state machines to specify sender and receiver sides. Now we will discuss state machines, how we have developed the protocol. we have a finite state machine it tells us about the modeling of the protocol finite state machine is used for mathematical modeling here we have used a simple finite state machine and between states there are two states state to another, we transition to an event and on the basis of that event, what action will be performed on that basis. If you are going from state 1 to state 2, then obviously an event must have occurred and as a result of that event, you must have performed some action, that is why you are moving from this state to another state. When you are in a particular state, the next state is uniquely determined by the next event. So, when you will go to the next state, this determines your event. So, we will see first of all, our basic case is RDT 1.0. RDT 1.0 is our first step towards developing reliable data transfer protocol. So, it should be very simple, very smooth so that we understand it. So, Assumptions are that the underlying channel will become complex. This is a base case, so it should be very simple to get a complete understanding of how to make a reliable data transfer protocol. So we are assuming that our underlying channel is completely reliable and it does not have reliability so that we can design a protocol easily and we can understand it. So in RDT 1.0 we are saying that our underlying channel is reliable that means it neither has any bit flip nor can we lose any packet. So we make a finite state machine for sender and receiver. Sending side sends data to underlying channel which is completely unreliable as discussed above and the receiving side receives data from reliable channel Now here the reliability factor is very important Here if there is reliable data transfer then neither bit flips nor the loss of the packet is there This dotted line tells us that this is our initial stage Initially when there is no packet, then your protocol is waiting for the data application layer to be generated and that data is sent. Let's suppose we say that a process 1 generated data, so now its wait will end. As soon as P1, process 1, calls the function of RDT send, the data is sent by process 1. If you understand the previous slide, you will understand that the RDT send function is called by the application layer. So, the application layer called the function of RDT send, so its wait ended here. What will be the action performed in the response of RDT send event? that transport layer will make packet of that data make packet function will be called and packets will be made and will call RDT protocol UDT send function and packet will send over a reliable channel which we have already discussed perfectly reliable channel to receiver ok so when packet will receive to receiver so what will happen from the layer below RDT receive function will be called It received the packet. Now, the event ReceivePacket, it has received the packet through the receive function of the RDT variable data transfer protocol. So, in the response of this event, the action will be performed that the data in that packet will be extracted. The packet extracted the data and delivered to the application layer. So, now we have to translate from this state to this state when we have packets. So, translate means when your packet goes from sender to receiver, when the packet was there, it went. Otherwise, your finite state machine, your protocol will wait for it to get a packet so that it can send. I hope you understood RGT-1. Now let's move. This protocol that we have, We have a simple protocol which is not close to reality. We don't have a reliable channel in real life which neither flips the bit nor encounters packet loss. So we are trying to develop a slightly reliable protocol. We said that RDT 2.0 is a bit complex version of RDT protocol. In which we have assumed that now the channel that is being used between the two senders is not completely reliable but it can cause bit error. Now what does bit error mean? Suppose you are sending 101 data and in the first bit the data is flipped and the data you receive is 001. So we have 1 bit which has been flipped. So, what is the assumption? Underlying channel may flip the bit in the packet. So, we have already discussed in UDP that if there is a bit error, what is the procedure to detect it? We have a procedure that we can apply the method of checksum and detect it. Now, the question is that what to do if it is detected? UDP discards it, but we have a protocol here that we have to make reliable data transfer reliable. The next question is how to make sure? How to recover from the error? If the error has come, then we cannot discard all the data. Now how to recover from this error? You will give me the answer to this question. You will pause the video and think how to recover a human being from error. Let's suppose you are calling and if the next person does not understand what you are saying, then what will he say to you over the phone? Please repeat. When you will understand these words, you will have to repeat your previous sentence. Let's suppose you are getting something dictated, so if you are asked to repeat this, you will repeat it. If you don't want to repeat it, then it will say okay. That means the previous line you said will be received correctly and the next line will be sent. So, this means that the feedback is coming from the receiver, on the basis of which you will either repeat or continue. So, in RDT 2.0, we also use a feedback procedure to recover from errors. And what is that feedback? Either it is an acknowledgement or a negative acknowledgement. What is the meaning of acknowledgement? The packet you sent, the receiver will send it to the sender. explicitly tells you that your packet has been received correctly, now go on to the next packet which you have to send, send that. But if the receiver explicitly sends a negative acknowledgement, then it means that the packet you had sent earlier has an error in it, retransmit that packet. So, what does the sender do? It retransmits whenever it gets a negative acknowledgement. So, let's settle down here. We say that our acknowledgement is of 1 bit. If 0 is received in the acknowledgement, then we will say that this is a positive acknowledgement. And if 1 is received in the acknowledgement, then we will say that this is our negative acknowledgement. As soon as 1 is received, we will retransmit it. So, the new mechanism of RGC 2.0 It is doing error detection using checksum but it is also doing error recovery using feedback through control messages of acknowledgement and negative acknowledgement. So, we will discuss how to make finite state machines. First of all, we have two states of sender and receiver. So, transit from one the state to another would be according to the event okay event and wait for the uh for acknowledgement or negative acknowledgement as we've already uh already discussed So, first of all, we are waiting for the application layer to send the data by using RDT send function. So, first of all, let's suppose we have to send the data in P1, then what will it do? It will call the RDT send function. So, first of all, wait for the call from above and here also wait for the call from below. Both are in waiting state. Now we say that application layer called the rdt send function It sent the data to transport layer So the transport layer's work is to make the packet of that data And embed checksum with every packet Why checksum? For error detection And by making packet it has to call the function of udt send Through which this is send packet For opening the send packet is sent through the udt send function now this packet will come to the receiver so as soon as the rdt send function is called after sending the packet, the sender is waiting for the acknowledgement if the packet is received correctly, the receiver will send the acknowledgement If it is not correctly received, then the receiver will send it negative acknowledgment. So, first we suppose that your packet is correctly received. So, we saw here that as soon as the function of RDT send was called, then actions were performed as a result of that, the packet was made and the function of UDT send was called. And our sender went for acknowledgement and negative acknowledgement. And on the receiving side, the receiver called the RDT receive function. and checked if the packet received is corrupted so what action will be performed on this basis? extract received packet from received packet, data will be extracted and application layer will be delivered and UDT send will be asked to send acknowledgement the packet that it sent to the sender has been received correctly so now what will happen? now the receiver will send acknowledgement through udt send so now we have here because we were waiting for acknowledgement or negative acknowledgement so here when the rdt receive function receives the packet and will see that this receiving packet is basically an acknowledgement packet so the symbol given below means no action okay no action so no action will be performed and our sender which is in the state will be continued so our sender went back to the state wait for the call from above now it is waiting again for the process to generate data again and call the rgt send function if let's suppose you see this symbol written above then it means no event but action is being performed because the symbol is below, so we will say that it is a symbol of no action. Now let's suppose we say that a package has been generated again. The packet is generated, wait for the call from above or wait for the call from below. Now the packet is generated and the RDT send function is called. What action will be performed in the result of calling the RDT send function? The make packet function will be called, data will be kept in it, checksum will be kept and the packet will be sent through UDT by making a send packet. As soon as that packet will be received by the receiver, RDT receive function will be called and checked whether the packet is corrupted or not. If the packet is corrupted, it will not deliver the packet by extracting it. What will it say? It will ask UDT send to send the negative acknowledgement to the sender. So, from here, the negative acknowledgement will be sent to the sender. The sender accepted the packet of receive and saw that the packet has negative acknowledgement. So, it will do the UDT send packet function again. It has to send the same packet again. Now when that packet is received, it will be checked that the received packet is not corrupted. If it is not corrupted, then that packet will be extracted. Data will be extracted from it and the function of deliver data will be passed. After delivering the application layer, the function of UDT send will be called. In which acknowledgement will be sent. the data that we have sent to the sender has been received correctly so as a result of this you do not perform any action but transfer the next data so this is our RDT 2.0 through which we have seen the acknowledgement or feedback procedure that how we are modeling our protocol in FSM now we will talk about what is the error in this What is the flaw in the protocol design? I will suggest you to pause your screen and think about the errors and flaws in the protocol design. I will give you a hint. We have one bit of acknowledgement or negative acknowledgement. We are saying that either send 0 bit for acknowledgement and 1 bit for negative acknowledgement and also this channel has a flaw that it flips the bits Now you should understand what is the flaw in RDP 2.0 So pause this and think and we will discuss what is the flaw Basically, RGT 2.0 is a protocol that has a channel which has the ability to flip the bits. We are saying that the negative acknowledgement and acknowledgement is one bit. One for negative acknowledgement, zero for positive acknowledgement and acknowledgement. So, if we send it from here, zero. Acknowledgement means that the data going from here is going to zero. But over the unreliable channel, it flipped and became one. So here the packet will receive negative acknowledgement. So this means that the UDT send function will be called and that packet will be sent to you again. Although that packet is already present here. We are saying that PKT was a packet that we got and as a result we sent the acknowledgement. But that acknowledgement flipped in the way and it became 1 instead of 0. So, here when the negative acknowledgement is received, the packet will be sent again. So, here we will get the packet again. So, which packet should be delivered, which should be discarded or why should the packet be discarded, this becomes a fatal flaw here. See, what is this flaw? What if acknowledgement or negative acknowledgement got corrupted? So, what will we do? Sender does not know what happened at the receiver. Can't just retransmit the packet. which can create possible duplicate. So, what is the way to handle duplicate? The sender will retransmit the acknowledgement, retransmit the current packet if acknowledgement or negative acknowledgement is corrupted. So, the solution of sender is that we send sequence number with every packet. As soon as the receiver receives two packets of one sequence number, then he will discard one and deliver one. So, receiver discard does not deliver up the duplicate packet. So, if he receives two packets of one sequence number, then he will discard one and deliver one. These protocols are basically waiting for the next package to be sent until they receive acknowledgement or negative acknowledgement they are waiting until they generate the next package or transfer the next package So these protocols are called stop and wait protocols If a protocol is waiting for a response or feedback of previous packet so that it can send the next packet, then we call such protocols as stop and wait protocol. No doubt response time of such protocols is very less because they are waiting for the response of previous packet so that they can send the next packet. So, these are the stop and wait protocols. which are reliable data transfer protocols which are doing retransmissions we call such protocols ARQ which is automatic repeat request protocol what is it called? automatic ARQ protocol those protocols which are used to make reliable data transfer reliable We call those protocols automatic repeat request protocols. Automatic repeat request. R-E-Q-U-E-S-D. This is request queue. And this is automatic. repeat automatic and R for repeat and Q for request so these are automatic repeat request protocols so these are the definition of automatic repeat request protocols and stop and wait protocols Now we will talk about how our RDT 2.0 flaw is handled by RDT 2.1 We have already discussed RDT 2.1 protocol that the flaw in RDT 2.0 was that it did not have the capacity to handle duplicate packets So this protocol, RDT 2.0 protocol was further enhanced by adding the sequence number So Now, what is done is that whenever a package is made on the sender side, sequence number is added there. Two sequence numbers are enough for us for now. One sequence number will be zero and one sequence number will be one. First, the zero sequence number package will be sent. When it will be received, its acknowledgment will be received. After that, we will send one packet. Must check if the received acknowledgment or negative acknowledgment got corrupted. Now, what is the procedure to check this? We have already discussed that if we want to detect something that is corrupted or not, then we have the checksum procedure. Twice as many states as previous. As we saw in the previous state machine, we had two states on the sending side and one state on the receiving side. In the same way, we will double it in this protocol. We will have four states on the sending side and two states on the receiving side. On receiving side, as soon as the packet is received, must check if the received packet is a duplicate or not. If it is duplicate, then one will be discarded and the other package will be delivered. Note that receiver cannot know if its last acknowledgement or negative acknowledgement is okay at the sender. So, even now, we don't have this team in this that our acknowledgement we are sending is getting received okay or is getting flipped in the way. Yes, we are handling duplicate packets here. That's all for RDT 2.1. In our next chapter, we will discuss how to represent RDT 2.1 protocol in finite state machine and also how to get rid of the negative acknowledgement cycle. reliable data transfer protocol design. So I hope you understood this. If you have any queries, you can ask them. That's all for today's topic.

What facilities does it provide and how does UDP perform error detection by using checksum? So, our topic for this week is about principles of reliable data transfer. When we discuss topics in this chapter, the generic pattern that we see is that generic data transfer is a process of What is the perspective of a topic? Let's suppose we are saying what is reliable data transfer in general? Then we will discuss how the CCP implements the facility of reliable data transfer.

So in this topic we are generically discussing what is reliable data transfer basically? How do we design a protocol in which we ensure that our data from one point to another will be reliably transferred over an unreliable channel? So let's say we have a data transfer in a particular country. Because if we talk about real life, we send data on a highly unreliable channel in which all kinds of interference can be encountered.

So, on that highly unreliable channel, how can you design a protocol on the transport layer which can reliably transfer your data over an unreliable channel to the destination. So, this is our main purpose of this topic which is known as principles of reliable data transfer. So, let's start.

If we talk about principles of reliable data transfer, the top 10 trending topics in the computer network so far, we have reliable data transfer in the top 10. Because it is very important. At the same time, if we talk about which layer is important for reliable data transfer, it is not only important for the transport layer, it is as important for the data link layer as well. So, we say that the reliable data transfer is important for multiple layers, so it is a trending topic.

So, when we talk about reliable data transfer, we have the application layer, that layer where processes are being run and data is being generated. So, as soon as data is generated, it is sent to the transport layer. We have already discussed the work of the transport layer, that it has to divide data into chunks, add headers and then network layer network layer comes to data link layer data link layer comes to physical layer and physical layer forwards it to the destination now we have provided model if I see its service implementation then what will be the service implementation The application layer generates the data and calls the RDT send function.

Now we have come to the protocol designing. How will the reliable data transfer protocol work? So, first of all, we have the application layer that generates the data, called the RDT send function, the RDT send function will take the data from the application layer and will bring it to the transport layer here. Now we have to design a protocol on the transport layer which is known as the reliable data transfer protocol. RDT means Reliable Data Transfer Send function So, the function of Reliable Data Send is called and the data is fetched on the transport layer Now, what we have to do with the Reliable Data Transfer Protocol is We have to divide the data in chunks, add the header, and add the reliability features And then, using the UDT send function, this data force and the reliability features on the data, and then send the data over an unreliable channel.

So, note that when the data was coming, we were calling it data, but when the reliable data transfer protocol is sending the data, we are calling that data packet. Now we have sent this packet on unreliable channel. When this packet will reach receiving side, there is a protocol receiver, which is a function of reliable data transfer, which is known as RDT receive.

That function has to receive that packet. It has to check that this data is received correctly, there is no error in it or whatever. This is the work of reliable data transfer protocol.

It has to retrieve and extract that data. If that data is correct, it will deliver that data to the application layer. Now, this work of reliability checking or error detection or error recovery, this work has to be done by reliable data transfer protocol.

If we talk about the previous topic of connectionless UDP, then we discussed that checksum is a technique that is used to detect errors. it is not a technique that helps you to recover from error UDT does not give you the procedure of recovery UDT says that if your data is detected that it is error prone data then you have to either discard that data or you have to send the same data which contains error to the application layer with a warning that this data may contain error So, you forwarded the application layer with warning. Now, UDT does not decide how to recover from that error. This feature is not present in UDT.

UDT has a feature of detection and not a feature of recovery. So, characteristics of an unreliable channel will determine the complexity of the reliable data transfer protocol. This thing, if you don't get this right now, In the future, when we discuss our next slide, this will be more clear to you. Here it is discussed that how complex your protocol will be.

It is conditional on this thing. You can say that it is connected to this thing that how unreliable is your channel. If that channel is more unreliable, that means that error is also and there is packet loss, then the protocol you have to make will be very complex.

But if you have a channel on which you know that the packet can only be flipped and not loose, then your protocol designing will be a little easier. This means that the more your underlying channel is unreliable, the more the complexity of your protocol will increase. If you still do not understand this, then we will discuss it in the future. Now we will discuss the topic of... Now, we have seen the previous service model implementation, in which the RDT send function we have already briefly discussed what it is, but once again I am present in the slides that how the RDT send function is called.

RDT underscore send, reliable data transfer underscore send function is called from above, that is from application layer, which is used so that data can be passed on to the gate. the transport layer. Now, RDT send calls this function on the sending side and then UDT send function calls the transport layer so that this function is called by RDT so that UDT underscore send function is called so that your packet and transfer it over an unreliable channel so that it can reach the receiver. Now on the receiving side, there is a function called RDT underscore receive which is called when a packet comes on the receiving side. Now the function of the delivered data is called by RDT, the protocol of reliable data transfer so that the data extracted from the packet, that data is transferred to the upper layer of the application.

So if we have an application layer from the upper layer of the application, then that data is transferred to it. transfer. So this is how service implementation should be.

Now we are moving towards the steps of our reliable data transfer protocol. So we will develop our reliable data transfer protocols incrementally so that you have a clear idea of how the protocol is designed. First of all, The point that was put here is that the sender side or the receiver side has to develop the protocol incrementally from both sides.

It is not that we start discussing a very complex protocol all the way and you don't understand what that protocol is. We will discuss the protocol gradually as to what protocol designing is. So, for protocol designing, we have taken some assumptions.

We are saying that consider only Unidirectional Data Transfer Why we are talking about unidirectional data transfer? Because we are sending data to sender and receiver Obviously if it is requested for data then it will reply But in this scenario of Reliable Data Transfer Protocol In this we are talking about unidirectional data transfer And we are talking about unidirectional data transfer only for data Not for the control information Now what is the difference between data and control information? That we have that information or file, text file, image file, audio file, video file, so I have this data transfer.

But if that video file is received, then it is getting an OK message or if it is not received, then I am getting a not OK message. So this is called control information. So the point I want to tell here is that your data transfer is unidirectional.

Control information will come from both sides. If you send data from here, then if you want to buy that data, If you receive the message correctly, you will receive an OK message. That is two-way communication. The receiver will send the control information back, but not the data. We have to keep this assumption in mind.

Use finite state machines to specify sender and receiver sides. Now we will discuss state machines, how we have developed the protocol. we have a finite state machine it tells us about the modeling of the protocol finite state machine is used for mathematical modeling here we have used a simple finite state machine and between states there are two states state to another, we transition to an event and on the basis of that event, what action will be performed on that basis.

If you are going from state 1 to state 2, then obviously an event must have occurred and as a result of that event, you must have performed some action, that is why you are moving from this state to another state. When you are in a particular state, the next state is uniquely determined by the next event. So, when you will go to the next state, this determines your event. So, we will see first of all, our basic case is RDT 1.0.

RDT 1.0 is our first step towards developing reliable data transfer protocol. So, it should be very simple, very smooth so that we understand it. So, Assumptions are that the underlying channel will become complex.

This is a base case, so it should be very simple to get a complete understanding of how to make a reliable data transfer protocol. So we are assuming that our underlying channel is completely reliable and it does not have reliability so that we can design a protocol easily and we can understand it. So in RDT 1.0 we are saying that our underlying channel is reliable that means it neither has any bit flip nor can we lose any packet. So we make a finite state machine for sender and receiver. Sending side sends data to underlying channel which is completely unreliable as discussed above and the receiving side receives data from reliable channel Now here the reliability factor is very important Here if there is reliable data transfer then neither bit flips nor the loss of the packet is there This dotted line tells us that this is our initial stage Initially when there is no packet, then your protocol is waiting for the data application layer to be generated and that data is sent.

Let's suppose we say that a process 1 generated data, so now its wait will end. As soon as P1, process 1, calls the function of RDT send, the data is sent by process 1. If you understand the previous slide, you will understand that the RDT send function is called by the application layer. So, the application layer called the function of RDT send, so its wait ended here. What will be the action performed in the response of RDT send event? that transport layer will make packet of that data make packet function will be called and packets will be made and will call RDT protocol UDT send function and packet will send over a reliable channel which we have already discussed perfectly reliable channel to receiver ok so when packet will receive to receiver so what will happen from the layer below RDT receive function will be called It received the packet.

Now, the event ReceivePacket, it has received the packet through the receive function of the RDT variable data transfer protocol. So, in the response of this event, the action will be performed that the data in that packet will be extracted. The packet extracted the data and delivered to the application layer.

So, now we have to translate from this state to this state when we have packets. So, translate means when your packet goes from sender to receiver, when the packet was there, it went. Otherwise, your finite state machine, your protocol will wait for it to get a packet so that it can send. I hope you understood RGT-1. Now let's move.

This protocol that we have, We have a simple protocol which is not close to reality. We don't have a reliable channel in real life which neither flips the bit nor encounters packet loss. So we are trying to develop a slightly reliable protocol.

We said that RDT 2.0 is a bit complex version of RDT protocol. In which we have assumed that now the channel that is being used between the two senders is not completely reliable but it can cause bit error. Now what does bit error mean?

Suppose you are sending 101 data and in the first bit the data is flipped and the data you receive is 001. So we have 1 bit which has been flipped. So, what is the assumption? Underlying channel may flip the bit in the packet. So, we have already discussed in UDP that if there is a bit error, what is the procedure to detect it? We have a procedure that we can apply the method of checksum and detect it.

Now, the question is that what to do if it is detected? UDP discards it, but we have a protocol here that we have to make reliable data transfer reliable. The next question is how to make sure?

How to recover from the error? If the error has come, then we cannot discard all the data. Now how to recover from this error?

You will give me the answer to this question. You will pause the video and think how to recover a human being from error. Let's suppose you are calling and if the next person does not understand what you are saying, then what will he say to you over the phone?

Please repeat. When you will understand these words, you will have to repeat your previous sentence. Let's suppose you are getting something dictated, so if you are asked to repeat this, you will repeat it.

If you don't want to repeat it, then it will say okay. That means the previous line you said will be received correctly and the next line will be sent. So, this means that the feedback is coming from the receiver, on the basis of which you will either repeat or continue.

So, in RDT 2.0, we also use a feedback procedure to recover from errors. And what is that feedback? Either it is an acknowledgement or a negative acknowledgement. What is the meaning of acknowledgement? The packet you sent, the receiver will send it to the sender.

explicitly tells you that your packet has been received correctly, now go on to the next packet which you have to send, send that. But if the receiver explicitly sends a negative acknowledgement, then it means that the packet you had sent earlier has an error in it, retransmit that packet. So, what does the sender do?

It retransmits whenever it gets a negative acknowledgement. So, let's settle down here. We say that our acknowledgement is of 1 bit.

If 0 is received in the acknowledgement, then we will say that this is a positive acknowledgement. And if 1 is received in the acknowledgement, then we will say that this is our negative acknowledgement. As soon as 1 is received, we will retransmit it. So, the new mechanism of RGC 2.0 It is doing error detection using checksum but it is also doing error recovery using feedback through control messages of acknowledgement and negative acknowledgement. So, we will discuss how to make finite state machines.

First of all, we have two states of sender and receiver. So, transit from one the state to another would be according to the event okay event and wait for the uh for acknowledgement or negative acknowledgement as we've already uh already discussed So, first of all, we are waiting for the application layer to send the data by using RDT send function. So, first of all, let's suppose we have to send the data in P1, then what will it do?

It will call the RDT send function. So, first of all, wait for the call from above and here also wait for the call from below. Both are in waiting state.

Now we say that application layer called the rdt send function It sent the data to transport layer So the transport layer's work is to make the packet of that data And embed checksum with every packet Why checksum? For error detection And by making packet it has to call the function of udt send Through which this is send packet For opening the send packet is sent through the udt send function now this packet will come to the receiver so as soon as the rdt send function is called after sending the packet, the sender is waiting for the acknowledgement if the packet is received correctly, the receiver will send the acknowledgement If it is not correctly received, then the receiver will send it negative acknowledgment. So, first we suppose that your packet is correctly received. So, we saw here that as soon as the function of RDT send was called, then actions were performed as a result of that, the packet was made and the function of UDT send was called.

And our sender went for acknowledgement and negative acknowledgement. And on the receiving side, the receiver called the RDT receive function. and checked if the packet received is corrupted so what action will be performed on this basis? extract received packet from received packet, data will be extracted and application layer will be delivered and UDT send will be asked to send acknowledgement the packet that it sent to the sender has been received correctly so now what will happen? now the receiver will send acknowledgement through udt send so now we have here because we were waiting for acknowledgement or negative acknowledgement so here when the rdt receive function receives the packet and will see that this receiving packet is basically an acknowledgement packet so the symbol given below means no action okay no action so no action will be performed and our sender which is in the state will be continued so our sender went back to the state wait for the call from above now it is waiting again for the process to generate data again and call the rgt send function if let's suppose you see this symbol written above then it means no event but action is being performed because the symbol is below, so we will say that it is a symbol of no action.

Now let's suppose we say that a package has been generated again. The packet is generated, wait for the call from above or wait for the call from below. Now the packet is generated and the RDT send function is called. What action will be performed in the result of calling the RDT send function? The make packet function will be called, data will be kept in it, checksum will be kept and the packet will be sent through UDT by making a send packet.

As soon as that packet will be received by the receiver, RDT receive function will be called and checked whether the packet is corrupted or not. If the packet is corrupted, it will not deliver the packet by extracting it. What will it say?

It will ask UDT send to send the negative acknowledgement to the sender. So, from here, the negative acknowledgement will be sent to the sender. The sender accepted the packet of receive and saw that the packet has negative acknowledgement. So, it will do the UDT send packet function again. It has to send the same packet again.

Now when that packet is received, it will be checked that the received packet is not corrupted. If it is not corrupted, then that packet will be extracted. Data will be extracted from it and the function of deliver data will be passed. After delivering the application layer, the function of UDT send will be called. In which acknowledgement will be sent.

the data that we have sent to the sender has been received correctly so as a result of this you do not perform any action but transfer the next data so this is our RDT 2.0 through which we have seen the acknowledgement or feedback procedure that how we are modeling our protocol in FSM now we will talk about what is the error in this What is the flaw in the protocol design? I will suggest you to pause your screen and think about the errors and flaws in the protocol design. I will give you a hint.

We have one bit of acknowledgement or negative acknowledgement. We are saying that either send 0 bit for acknowledgement and 1 bit for negative acknowledgement and also this channel has a flaw that it flips the bits Now you should understand what is the flaw in RDP 2.0 So pause this and think and we will discuss what is the flaw Basically, RGT 2.0 is a protocol that has a channel which has the ability to flip the bits. We are saying that the negative acknowledgement and acknowledgement is one bit. One for negative acknowledgement, zero for positive acknowledgement and acknowledgement. So, if we send it from here, zero.

Acknowledgement means that the data going from here is going to zero. But over the unreliable channel, it flipped and became one. So here the packet will receive negative acknowledgement. So this means that the UDT send function will be called and that packet will be sent to you again.

Although that packet is already present here. We are saying that PKT was a packet that we got and as a result we sent the acknowledgement. But that acknowledgement flipped in the way and it became 1 instead of 0. So, here when the negative acknowledgement is received, the packet will be sent again.

So, here we will get the packet again. So, which packet should be delivered, which should be discarded or why should the packet be discarded, this becomes a fatal flaw here. See, what is this flaw? What if acknowledgement or negative acknowledgement got corrupted? So, what will we do?

Sender does not know what happened at the receiver. Can't just retransmit the packet. which can create possible duplicate.

So, what is the way to handle duplicate? The sender will retransmit the acknowledgement, retransmit the current packet if acknowledgement or negative acknowledgement is corrupted. So, the solution of sender is that we send sequence number with every packet. As soon as the receiver receives two packets of one sequence number, then he will discard one and deliver one.

So, receiver discard does not deliver up the duplicate packet. So, if he receives two packets of one sequence number, then he will discard one and deliver one. These protocols are basically waiting for the next package to be sent until they receive acknowledgement or negative acknowledgement they are waiting until they generate the next package or transfer the next package So these protocols are called stop and wait protocols If a protocol is waiting for a response or feedback of previous packet so that it can send the next packet, then we call such protocols as stop and wait protocol.

No doubt response time of such protocols is very less because they are waiting for the response of previous packet so that they can send the next packet. So, these are the stop and wait protocols. which are reliable data transfer protocols which are doing retransmissions we call such protocols ARQ which is automatic repeat request protocol what is it called? automatic ARQ protocol those protocols which are used to make reliable data transfer reliable We call those protocols automatic repeat request protocols.

Automatic repeat request. R-E-Q-U-E-S-D. This is request queue. And this is automatic. repeat automatic and R for repeat and Q for request so these are automatic repeat request protocols so these are the definition of automatic repeat request protocols and stop and wait protocols Now we will talk about how our RDT 2.0 flaw is handled by RDT 2.1 We have already discussed RDT 2.1 protocol that the flaw in RDT 2.0 was that it did not have the capacity to handle duplicate packets So this protocol, RDT 2.0 protocol was further enhanced by adding the sequence number So Now, what is done is that whenever a package is made on the sender side, sequence number is added there.

Two sequence numbers are enough for us for now. One sequence number will be zero and one sequence number will be one. First, the zero sequence number package will be sent. When it will be received, its acknowledgment will be received.

After that, we will send one packet. Must check if the received acknowledgment or negative acknowledgment got corrupted. Now, what is the procedure to check this?

We have already discussed that if we want to detect something that is corrupted or not, then we have the checksum procedure. Twice as many states as previous. As we saw in the previous state machine, we had two states on the sending side and one state on the receiving side. In the same way, we will double it in this protocol. We will have four states on the sending side and two states on the receiving side.

On receiving side, as soon as the packet is received, must check if the received packet is a duplicate or not. If it is duplicate, then one will be discarded and the other package will be delivered. Note that receiver cannot know if its last acknowledgement or negative acknowledgement is okay at the sender. So, even now, we don't have this team in this that our acknowledgement we are sending is getting received okay or is getting flipped in the way.

Yes, we are handling duplicate packets here. That's all for RDT 2.1. In our next chapter, we will discuss how to represent RDT 2.1 protocol in finite state machine and also how to get rid of the negative acknowledgement cycle. reliable data transfer protocol design.

So I hope you understood this. If you have any queries, you can ask them. That's all for today's topic.

Transcript for:Understanding Reliable Data Transfer Protocols

Transcript for:
Understanding Reliable Data Transfer Protocols