1. Congestion Avoidance
Now, in this section we’ll talk about congestion avoidance mechanism used on the Cisco routers. Now, before we go ahead, we’ll try to quickly revise some of the basic wing mechanisms which we have discussed in our previous sections. And then we’ll try to understand what is exactly tail drop and what are the limitations. And then we’ll see some solution to overcome the tail drop issues. We call it as a rate, randomly detection weighted rate and class based weighted rate. Now, first let’s try to understand or quickly revise some of the basic wing mechanisms. Now, whenever any packet comes in general there is something called hardware queue which we cannot do anything, it’s always first and first out.
Before the packets are placed in the hardware queue, we are going to arrange them in a software queue and we are going to differentiate the traffic based on different class maps. Like, I’m going to include some high priority traffic like voice and video and then some low priority traffic and I’m going to reserve a specific amount of bandwidth or we have defined some priority for the voice traffic and then we can reserve some specific amount of bandwidth for other classification of the traffic. Now, this is something we have done in the previous sections, we call that as querying mechanisms using low latency queering or class based weighted fail querying. Now in this section we’ll see condition avoidance mechanisms like what happens if this software queue is full.
Now, once the software queue research is maximum limit, what it is going to do. Now, all your incoming packets, whatever is coming, it will be simply dropped automatically because already the software queue is full, it cannot accommodate more packets and it’s going to do something called tail drop automatically. Whatever the packets coming here, it will be automatically dropped irrespective, whether it is a voice or whether it’s a ftp or whether it’s a Http, there is no classification automatically, it is going to drop each and every packet. Now, we call this, this mechanism as a tail drop. Now, in this section we’ll try to understand some congestion avoidance mechanisms which will help us to ensure that your high priority traffic should not get dropped.
So some of the mechanisms like red and weight and red. Now just now we discussed tail drop is a mechanism where if you have a software queue is full and if there is new packets coming irrespective, whether it is voice traffic or ftp traffic, it’s going to automatically drop them. And the reason is the software queue has reaches the maximum limit and before it actually process any packets, there’s no space at all to accommodate any new packets, it’s going to drop automatically. So additional incoming packets will be dropped and drop packets can automatically have some significant application performance degradation and it has some drawbacks as well. So let’s try to understand what generally issues will come across if there is a tail drop happens so tail drop means incoming.
All packets are getting dropped automatically irrespective of any prioritization. So tail drop is going to treat each and every packet equally, whether it’s a voice traffic or whether it is the ftp traffic, it is going to treat both the traffic equally and once it reaches the maximum limit, it’s going to automatically drop all the packets. There is no differentiation mechanism and the major drawback with a tail drop is it is going to increase the bandage utilization more. In general, if there is a tail drop happens and there are some TCP related issues comes like TCP starvation and TCP Synchronization issues. Now let’s try to understand what is exactly TCP Synchronization issues.
Now, in case of TCP synchronization, what happens is tail drop causes most of the multiple TCP streams to go. Like normally it’s sending some multiple TCP streams. Now TCP is connection based. When it is sending anything, it expects the acknowledgment and if there’s no acknowledgement, it is going to resend the information, something like that. If you have some TCP based connections established here and if there is a congestion now there are some connections established here. Now, if the network realizes congestion automatically, whatever the maximum limit, once it reaches the maximum software limit, it’s going to drop. The incoming TCP sessions means half of the TCP sessions may be disconnected or dropped because of the condition.
Now this way there is a condition, it’s going to cause a large number of TCP sessions established and steady packets get dropped simultaneously at the same time. Now, even the TCP is having some TCP automatic recovery mechanism where when the sender is sending its sending rate for certain amount of time, it starts to find out that the network is no longer congested and increases the rate again. Now, in general, what happens is if the TCP realizes that there is a congestion, it’s going to slow down the trade and then after some time it’s going to realize that there is no condition and all the senders will start sending the information again at the same time.
So all the senders uses the same time delay before they actually increase the sending rate and then again suddenly it reaches the maximum limit and again it will start dropping again, which is again leading to the tail drop. So more packets are sending at a high speed and they realize their congestion, they will slow down after sometime, they’ll try again and then get dropped and they can slow down and then try again after sometime. Now, this pattern of sending decreasing and increasing the transmission again the rate at the same time is referred as global TCP Synchronization issues. Now, one of the major drawback with this TCP synchronization is it’s going to lead to insufficient utilization of your bandwidth due to large number of packets getting dropped.
And again they are retransmitted because they are dropped once it reaches the limit and they are retrasmitted again slowing down the rate and then again they are increasing the rate compared to the again the sender will reduce the sending rate when compared to the stable rate. Now these are the general issues you will find when it comes to TCP based connections. Now we really don’t want this. Now to overcome this, what we are going to do is we are going to use some condition, a one is mechanisms called red random led detection or weighted rate cisco implementation on that. Now what these mechanisms are going to do is they are going to drop the packets before they actually reach permit.
Now the main advantage we get with these mechanisms is it’s going to prevent the global TCP synchronization where we are going to manage the tail drop before it actually reaches the limit. It’s going to drop the packets selectively based on the weights, whatever we are applying on that. Now selectively dropping the traffic before the queue is actually full. Now tail drop happens generally when your queue is full but these mechanisms will ensure that it doesn’t reach the limit before it reaches the limit, the packets are getting dropped before it reaches the limit. Now these mechanisms will recognize the congestion before the queue is full and start signaling the individual TCP flows to slow down the sending rate.
Now this way we’ll ensure that your TCP messages are send at a slow rate without getting dropped, without creating multiple TCP sessions again and again. So we’ll talk about more on this mechanisms in our previous sections. Now in this section we have majorly reviewed some basics of quing mechanisms where Quing is a method of arranging all the packets, all the traffic in a different classifications and then giving different kind of treatment for each and every traffic. But still if that particular software use becomes full now there is a possibility that all your incoming packets get dropped. Now we call that as tail drop.
Now tail drop will have some issues with, especially with the TCP based traffic which will lead to TCP synchronization where you already have some TCP based sessions which can get dropped. Once it gets dropped it will slow down the rate and after some time they will feel that there’s no condition and all the signals will start sending at the same time and then realize the condition and then they will slow down. Now this is going to increase the bandwidth utilization due to insufficient of bandwidth, large number of packets getting dropped and then retransmitted and we have something called TCP synchronization issues and to overcome that we can use some mechanisms like red and weighted rate mechanisms.
2. WRED – CBWRED
Now in this section we’ll talk about the random Led detection mechanisms which is a congestion Awardance mechanisms to overcome the issues with a tail drop and tcp global synchronization issues. Like in the previous section we have seen a tcp Synchronization issues where so tcp Synchronization generally happens when where you have a large tcp streams coming up and because of the congestion your packets get dropped, it will increase the number of tcp sessions. But the pattern of sending decreasing or increasing the transmission rates at the same time is referred as tcp synchronization and also that happens generally based on the tail drops.
Now to overcome this, what we can do is we can implement some condition avoidance mechanisms called random Led detection. And what exactly it’s going to do is it is going to selectively drop the traffic before the queue is full. Now let’s say this is the maximum queue size before it actually reaches the limit it’s going to drop before the queue is actually full. Now it’s going to signal the individual tcp flows also to slow down the sending rate which will also avoid the tcp synchronization issues as well. Now in the random Led detection it is going to define three different parameters.
We are going to define the minimum threshold value, maximum threshold and the maximum drop probability values. Now before we go ahead with this, now this red mechanism is going to work only if there is if the hardware queue is full, if your queue is full then only it is going to work. If the queue is not full, none of these methods will start again. Now here it is going to define some minimum threshold value. Now the minimum threshold value is nothing, but we are going to define the level of packets at which we will begin the random draw process. Now we are going to define some minimum threshold value and anything below to this we are not going to drop anything once it reaches that limit.
We are going to define the value that it’s going to start a random drop random, it will stop dropping the traffic and we have something called maximum threshold value. The maximum threshold value is going to tell. Now anything between the minimum threshold to maximum threshold it’s going to do drops and once it reaches the maximum threshold it’s going to do something called tail drop. It’s going to drop each and every packet once it reaches the maximum threshold. So we are going to define some minimum threshold and maximum threshold values like how many packets should be present.
Let’s say if there are output queue supports, something about 40 packets I’m going to define saying that the minimum threshold value should be 25 and the maximum threshold value should be 35. So anything below 25 it’s not going to drop anything. Once it reaches 25 to 35 it’s going to randomly drop the packets and anything exceeding 35 it’s going to do the tail drop again. Now we’ll see how to define these parameters again more in detail in the implementation in our next video. We can even change these parameters. Now, the cisco deployed something called weight at random Led detection where we are going to apply some weight to a specific kind of traffic.
Like instead of dropping the traffic randomly, what we can do is we can define some weight. Let’s say you have a traffic coming with a presence value of one and the presence value of three. Now most likely presence value one will get dropped because of the less weight or it can be dscp values as well.We have your traffic coming with a dscp value of a of 21 and we have traffic with a eleven one. One is going to get dropped more likely than this one. So where it’s going to select the drop the packet based on the markings or based on the Quese markings or based on the weight we call it as. So that is what cisco addition to the existing random architecture mechanisms.
Now we can apply this either on the interface level or on the class level. So if you’re using some older iOS versions, you will have this option on the interface where we can go to the interface and we can simply say Random Detect and just press Enter. So if you do not define anything, it’s going to do the default based on the IP presence values. And if you want to change to dscp base, we can change this parameter here. Now we can define what exactly, what weight, exactly it has to see, or what qs marking it has to see when it starts dropping the traffic. Now, there are some predefined predefined Q lens for each and every presence value. Like if you’re using presence value of one, the minimum threshold will be 22.
If you’re using presence value the minimum threshold will change to 24 or even we can change this parameters manually. We’ll see this configuration as we go ahead in the previous sections. Now, if you go with the new iOS versions, you may not see this implementation on the interface. Now again, this configuration varies based on the iOS versions. Again, not all new iOS have checked that it supports only class level based random data configurations. Now the last implementation, we have something called class based weighted fare rate where we are going to create some classmaps like we did in the previous sessions and then we are going to match some specific amount of traffic voice or we are going to define our own parameters.
Like in the class one I’m going to match zero and one and in the class two I’m going to match the presence value of two and three. And in the class three I’m going to match the presence value of four. And I can define the red values, random detection values, where we can manually define what should be the minimum and the maximum three sold based on the class maps. In the class maps we are differentiating the traffic with voice or anything, and we are going to define some marking values and it’s going to treat based on the markings given by the administrator instead of using the default marking values. The conclusion wise, it’s simple. We need to get into the policy map and we need to simply say random detect. Like here you can see for Michigan mission critical traffic, we have enabled random detect here.
So the major difference between these three is like in the case of random Led detection, it simply simply randomly, before it reaches the maximum limit, it’s going to randomly drop the packets and there’s no weight applied here where all the packets are treated equally. And most likely the big size packets get stopped when you compare with the small size packets. And in the weighted rate. Weighted rate, it’s a cisco implementation where the random edit detection will be done based on the marking values or based on the weight. And nowadays in today’s network we use something called class based weighted rate, where we can define all the traffic in different class maps and we can define the define the marking values like minimum and the maximum threshold inside the class max. Also.
