WEBVTT 0:00:02.920000 --> 0:00:08.220000 Welcome to this video titled, congestion avoidance with preemptive cue 0:00:08.220000 --> 0:00:15.920000 drops. In this video I'm going to define what is cueing based congestion 0:00:15.920000 --> 0:00:21.120000 avoidance. We're going to look at some types of cueing based congestion 0:00:21.120000 --> 0:00:24.760000 avoidance and I'm going to specifically give you an overview of a couple 0:00:24.760000 --> 0:00:31.440000 of them called weighted random early discard and weighted tail drop. 0:00:31.440000 --> 0:00:37.180000 So what is cueing based congestion avoidance? 0:00:37.180000 --> 0:00:43.160000 So there are two, let me back up here for a second. 0:00:43.160000 --> 0:00:47.280000 We know that QS is all designed to deal with a situation where we have 0:00:47.280000 --> 0:00:54.280000 congestion. congestion as defined by an interface cue is becoming saturated 0:00:54.280000 --> 0:00:58.620000 and is either reaching the point or has reached the point where it has 0:00:58.620000 --> 0:01:03.120000 no room left and packets now have to be dropped and that can happen on 0:01:03.120000 --> 0:01:06.140000 the ingress side or on the egress side. 0:01:06.140000 --> 0:01:10.540000 Very rarely does it happen on the ingress as we're receiving packets. 0:01:10.540000 --> 0:01:14.160000 Most of the time we have egress congestion because we have a whole bunch 0:01:14.160000 --> 0:01:18.440000 of interfaces that are feeding packets into a router switch and they're 0:01:18.440000 --> 0:01:22.280000 all being funneled to one outbound interface and that's where congestion 0:01:22.280000 --> 0:01:26.680000 can happen. Now we want to avoid that. 0:01:26.680000 --> 0:01:30.300000 We want to prevent that outbound cue from getting congested. 0:01:30.300000 --> 0:01:32.900000 At a high level there's two ways to do that. 0:01:32.900000 --> 0:01:36.820000 We can implement cue as features that will act on our packets before they 0:01:36.820000 --> 0:01:41.400000 even get into that cue so that cue will never get congested using things 0:01:41.400000 --> 0:01:46.280000 like traffic policeers are typically done for that or we could implement 0:01:46.280000 --> 0:01:50.780000 some cue as features on the cue itself to prevent it from ever getting 0:01:50.780000 --> 0:01:54.840000 100% full and that's what this is referring to. 0:01:54.840000 --> 0:01:58.300000 So our goal here if we want to do it this way, if we want to do cue based 0:01:58.300000 --> 0:02:03.760000 congestion avoidance we're going to end up basically randomly dropping 0:02:03.760000 --> 0:02:15.060000 frames as they're sent to us. 0:02:15.060000 --> 0:02:20.560000 Okay so on switches there's a couple of typical ways you could do this. 0:02:20.560000 --> 0:02:24.940000 You could use weighted tail drop and weighted random early discard. 0:02:24.940000 --> 0:02:29.020000 A few switches also have their own method called dynamic buffer limiting. 0:02:29.020000 --> 0:02:32.400000 This is on a very small subset of Cisco switches. 0:02:32.400000 --> 0:02:37.420000 On routers you can also do weighted random early discard. 0:02:37.420000 --> 0:02:38.780000 That's also available. 0:02:38.780000 --> 0:02:43.240000 So in this video I'm not going to get into the gory details of how each 0:02:43.240000 --> 0:02:44.840000 one of these works. 0:02:44.840000 --> 0:02:48.840000 I'm primarily going to focus on the first two weighted tail drop and weighted 0:02:48.840000 --> 0:02:53.900000 random early discard just at a real high level to give you a feel for 0:02:53.900000 --> 0:02:55.680000 the differences between them. 0:02:55.680000 --> 0:02:59.960000 If you want some more details on these operational details as well as 0:02:59.960000 --> 0:03:03.400000 how to configure them and how to modify them I encourage you to go back 0:03:03.400000 --> 0:03:08.960000 to our INE website and look up some more so we'll go into the type of 0:03:08.960000 --> 0:03:10.440000 details that you're looking for. 0:03:10.440000 --> 0:03:14.340000 This is just to introduce you into these features. 0:03:14.340000 --> 0:03:21.300000 Okay so both red and WTD your weighted tail drop has some common terminology. 0:03:21.300000 --> 0:03:25.240000 Number one they have something called drop thresholds. 0:03:25.240000 --> 0:03:28.980000 Now both of these things remember both of these are features that at their 0:03:28.980000 --> 0:03:35.180000 heart deal with the cue and deal with this idea of hey as traffic is being 0:03:35.180000 --> 0:03:39.480000 directed to the cue okay so it's come in let's just do it like this just 0:03:39.480000 --> 0:03:43.100000 to give you a visual of this. 0:03:43.100000 --> 0:03:47.120000 So here is my egress interface. 0:03:47.120000 --> 0:03:58.220000 Here is the buffer or cue that's storing everything and here are my ingress 0:03:58.220000 --> 0:04:05.640000 interfaces. Okay and packets are being directed by the forwarding engine 0:04:05.640000 --> 0:04:10.200000 into this egress cue. 0:04:10.200000 --> 0:04:16.260000 Both weighted red and weighted tail drop at their heart have the same 0:04:16.260000 --> 0:04:17.940000 general purpose. 0:04:17.940000 --> 0:04:21.640000 The idea is or I should say there's same general way of doing things which 0:04:21.640000 --> 0:04:26.480000 is hey rather than letting all this stuff into the egress cue I'll just 0:04:26.480000 --> 0:04:31.080000 call it the transmit cue. 0:04:31.080000 --> 0:04:36.080000 Let's drop some things even before they get there like this guy let's 0:04:36.080000 --> 0:04:41.340000 just drop that which will free up that one little space in the cue there. 0:04:41.340000 --> 0:04:44.380000 I can delete it without deleting everything. 0:04:44.380000 --> 0:04:48.820000 There we go and now that's freed up. 0:04:48.820000 --> 0:04:52.820000 So that's the idea behind both of these now they just do it slightly different 0:04:52.820000 --> 0:04:56.980000 ways. So the first thing is we have to understand this concept of drop 0:04:56.980000 --> 0:04:59.600000 thresholds what is that? 0:04:59.600000 --> 0:05:04.980000 Well drop thresholds you have minimum and maximum drop thresholds what 0:05:04.980000 --> 0:05:08.540000 do these refer to these refer to when we're going to start dropping things 0:05:08.540000 --> 0:05:13.820000 if the cue is completely empty there's not necessarily a need to drop 0:05:13.820000 --> 0:05:18.220000 something. So you need to think to yourself okay as the cue starts filling 0:05:18.220000 --> 0:05:23.900000 up and remember if there's no congestion the moment something's put in 0:05:23.900000 --> 0:05:26.200000 that cue bam it's gone. 0:05:26.200000 --> 0:05:29.960000 I mean when there's no congestion that cue doesn't get filled up at all. 0:05:29.960000 --> 0:05:33.160000 So the only time it starts filling up is that when we're putting stuff 0:05:33.160000 --> 0:05:37.360000 in there at such a fast rate that the egress interface just can't transmit 0:05:37.360000 --> 0:05:41.760000 it fast enough. So when that starts happening now the first question you 0:05:41.760000 --> 0:05:44.260000 have to ask yourself is this. 0:05:44.260000 --> 0:05:49.520000 So imagine that this is my cue right here hopefully it'll always stay 0:05:49.520000 --> 0:05:54.800000 right around here really low but as the packets start filling up at some 0:05:54.800000 --> 0:06:00.700000 point at some point you're going to want to start dropping things dropping 0:06:00.700000 --> 0:06:05.740000 packets as they're directed to this cue that's called your minimum threshold 0:06:05.740000 --> 0:06:11.900000 when the drops begin. 0:06:11.900000 --> 0:06:16.580000 And then as if it keeps going up you might reach another point where you 0:06:16.580000 --> 0:06:21.020000 say hey if it reaches this point I really need to become about as aggressive 0:06:21.020000 --> 0:06:23.180000 as I can possibly get. 0:06:23.180000 --> 0:06:28.760000 So I at least have some room up at the top that would be considered your 0:06:28.760000 --> 0:06:32.800000 maximum threshold. 0:06:32.800000 --> 0:06:36.860000 So let's take a look at how this could work as far as weighted tail drop 0:06:36.860000 --> 0:06:42.400000 is concerned. Now weighted tail drop is not the ideal mechanism to do 0:06:42.400000 --> 0:06:46.960000 this but on a lot of routers and especially switches that do QS and hardware 0:06:46.960000 --> 0:06:49.680000 a lot of times you don't have a choice. 0:06:49.680000 --> 0:06:52.640000 You might have if you turn on QS you might only have one thing you can 0:06:52.640000 --> 0:06:55.880000 do because it's done in an ASIC and you can't really change the behavior 0:06:55.880000 --> 0:07:00.720000 of that ASIC. So if weighted tail drop is your only option here's how 0:07:00.720000 --> 0:07:06.220000 it works. So this is done on most switches and it has some configurable 0:07:06.220000 --> 0:07:09.240000 thresholds and DSCP to threshold mappings. 0:07:09.240000 --> 0:07:10.500000 What does that mean? 0:07:10.500000 --> 0:07:13.260000 Alright well here let's go ahead and dig into this. 0:07:13.260000 --> 0:07:21.800000 So for example with weighted tail drop you could define one threshold 0:07:21.800000 --> 0:07:29.760000 your minimum threshold as maybe 40% okay. 0:07:29.760000 --> 0:07:32.820000 Now with weighted tail drop here's the way it works. 0:07:32.820000 --> 0:07:37.780000 Not only do you define the threshold at a certain number like hey when 0:07:37.780000 --> 0:07:43.420000 it gets to 40% full or 30% full you also define you say okay once I get 0:07:43.420000 --> 0:07:54.260000 to that level at that point as data comes in I'm going to drop 100% of 0:07:54.260000 --> 0:08:01.040000 all the data that comes in if it matches a certain criteria like this. 0:08:01.040000 --> 0:08:04.740000 We know that this is looking at costs right here right and let's just 0:08:04.740000 --> 0:08:07.940000 do a quick review of that. 0:08:07.940000 --> 0:08:15.860000 So we know that when you come to an IP packet let's just deal with IP 0:08:15.860000 --> 0:08:26.700000 version 4 right now for 8 in there 8 bits long and we know that IP precedence 0:08:26.700000 --> 0:08:31.400000 is dealing with the first 3 bits. 0:08:31.400000 --> 0:08:35.160000 And with those first 3 bits let's just put this up here so I have a little 0:08:35.160000 --> 0:08:42.520000 bit more room your precedence bits you could have a value of 0 as your 0:08:42.520000 --> 0:08:48.660000 minimum value up to a value of 7 as your maximum value. 0:08:48.660000 --> 0:08:56.520000 So what this graphic is showing is one queue that's all of it is going 0:08:56.520000 --> 0:09:03.540000 in there. So we have an interface here's my interface and here is this 0:09:03.540000 --> 0:09:09.060000 queue and as packets are coming in from various other ingress interfaces 0:09:09.060000 --> 0:09:12.220000 they're all going into this one queue. 0:09:12.220000 --> 0:09:15.500000 And by the way on switches a lot of switches what they'll do you might 0:09:15.500000 --> 0:09:18.680000 be saying well wait because I can Keith this is saying cost and you just 0:09:18.680000 --> 0:09:20.260000 talked about precedence. 0:09:20.260000 --> 0:09:26.340000 Yes so a lot of switches the way they will operate is that whatever the 0:09:26.340000 --> 0:09:31.520000 IP precedence is of a packet sort of internally in the switch you will 0:09:31.520000 --> 0:09:34.940000 never actually see this externally with like a packet sniffer or something 0:09:34.940000 --> 0:09:40.840000 but internally packets or frames will be given what's called an internal 0:09:40.840000 --> 0:09:46.280000 cost value just for the purposes of queuing and queue us mechanisms. 0:09:46.280000 --> 0:09:50.000000 So a lot of times on switches what they'll do is they will first discover 0:09:50.000000 --> 0:09:55.180000 what the IP precedence or DSCP value is or they might set the IP precedence 0:09:55.180000 --> 0:10:01.560000 or DSCP value to some number and then they will derive an internal cost 0:10:01.560000 --> 0:10:04.200000 value from that number. 0:10:04.200000 --> 0:10:07.640000 Okay but the main point I wanted to give was that just like IP precedence 0:10:07.640000 --> 0:10:12.560000 is a three bit value cost is also three bit value. 0:10:12.560000 --> 0:10:16.700000 So if I have an IP precedence of four that'll give me a cost value of 0:10:16.700000 --> 0:10:19.160000 four it's a one for one mapping. 0:10:19.160000 --> 0:10:24.660000 Okay so in this case we have a queue here that's storing all of it. 0:10:24.660000 --> 0:10:29.120000 And the way way to tail drop works is you say okay threshold number one 0:10:29.120000 --> 0:10:36.240000 I may have threshold number one these values these cost values of zero 0:10:36.240000 --> 0:10:40.540000 one two and three and I'm going to set threshold number one to a certain 0:10:40.540000 --> 0:10:44.140000 level like 40 percent. 0:10:44.140000 --> 0:10:49.220000 What that means is that if we get to this level if this gets all filled 0:10:49.220000 --> 0:10:54.400000 like this we're at that level now any packets that try to get into that 0:10:54.400000 --> 0:11:00.540000 queue with a cost value of zero one two or three we're going to kill those 0:11:00.540000 --> 0:11:03.200000 packets we're not going to let them in. 0:11:03.200000 --> 0:11:07.560000 Now you might say but Keith but look at this we still have 60 percent 0:11:07.560000 --> 0:11:11.060000 of the queue that's unutilized is empty. 0:11:11.060000 --> 0:11:16.940000 Doesn't matter with weighted tail drop you define a threshold you define 0:11:16.940000 --> 0:11:21.180000 the values that map to that threshold and once you meet that value once 0:11:21.180000 --> 0:11:27.500000 you meet that number no more packets can enter that queue that match those 0:11:27.500000 --> 0:11:31.680000 values. So in a sense what we're doing here is we're saying hey all of 0:11:31.680000 --> 0:11:38.240000 this space is reserved for these cost values whether we're seeing them 0:11:38.240000 --> 0:11:42.640000 or not whether they're coming into this queue or not is irrelevant this 0:11:42.640000 --> 0:11:45.520000 value is reserved for them. 0:11:45.520000 --> 0:11:50.040000 And then typically the second threshold is set to 100 percent because 0:11:50.040000 --> 0:11:53.500000 clearly once we reach 100 percent we've got nothing left. 0:11:53.500000 --> 0:11:56.560000 So you can see why I said at the beginning of this slide here that this 0:11:56.560000 --> 0:12:02.320000 is not an ideal situation because if you set threshold value number one 0:12:02.320000 --> 0:12:07.780000 two low like I did like it let's say you said 20 percent or something. 0:12:07.780000 --> 0:12:13.080000 Well that's a whole bunch of space up here 80 percent of the queue that 0:12:13.080000 --> 0:12:19.200000 might not ever be used if for the next hour or day or week the only packets 0:12:19.200000 --> 0:12:23.580000 are allowed in here or they're being directed to here are zeros ones twos 0:12:23.580000 --> 0:12:28.880000 or threes we're only giving them this much 80 percent is just sitting 0:12:28.880000 --> 0:12:33.280000 there idle because we're never seeing the four or five sixers or sevens. 0:12:33.280000 --> 0:12:36.600000 But that's how weighted tail drop works that's how it tries to reserve 0:12:36.600000 --> 0:12:41.100000 space in the queue for the more important traffic. 0:12:41.100000 --> 0:12:45.620000 Well some very smart people a lot smarter than me looked at this and they 0:12:45.620000 --> 0:12:50.840000 said you know what this isn't very efficient. 0:12:50.840000 --> 0:12:57.240000 What would probably be better is if we said okay yep I'll define a threshold 0:12:57.240000 --> 0:13:01.380000 threshold one at maybe oh I don't know let's say 40 percent. 0:13:01.380000 --> 0:13:08.100000 I'll do that and I'll map some values to that threshold but let's do something 0:13:08.100000 --> 0:13:09.840000 a little bit different. 0:13:09.840000 --> 0:13:16.200000 Why don't we do this once we reach that threshold instead of just dropping 0:13:16.200000 --> 0:13:20.320000 every subsequent packet that comes in at this level let's do it like this. 0:13:20.320000 --> 0:13:25.660000 Why don't we randomly drop some packets in other words let's say that 0:13:25.660000 --> 0:13:27.260000 all of these right here. 0:13:27.260000 --> 0:13:31.300000 Our packets are trying to come in. 0:13:31.300000 --> 0:13:41.560000 And these have various values of 0 3 1 2 0 1 okay so they all map to this. 0:13:41.560000 --> 0:13:44.840000 Now if I was doing weighted tail drop we'd be done we've already reached 0:13:44.840000 --> 0:13:48.140000 this right here it's already this full so all those packets would have 0:13:48.140000 --> 0:13:48.980000 to be destroyed. 0:13:48.980000 --> 0:13:52.680000 They would not be allowed in but wouldn't it be better if we could say 0:13:52.680000 --> 0:13:57.400000 you know what instead of doing that why don't we do this. 0:13:57.400000 --> 0:14:00.880000 Why don't we start randomly dropping like it at the first threshold when 0:14:00.880000 --> 0:14:06.040000 we hit that why don't we start randomly dropping one out of one out of 0:14:06.040000 --> 0:14:12.220000 ten packets. So maybe we'll drop this guy right here let's just discard 0:14:12.220000 --> 0:14:15.060000 him and let the other ones in. 0:14:15.060000 --> 0:14:20.760000 Now if the if the queue continues to get more full though then we can 0:14:20.760000 --> 0:14:25.380000 increase our rate of drop to maybe one out of every five and so now we'll 0:14:25.380000 --> 0:14:27.000000 be dropping a few more. 0:14:27.000000 --> 0:14:33.540000 That way we don't have all this unused space here but by doing these random 0:14:33.540000 --> 0:14:38.000000 drops we're still leaving a little bit of room just in case the important 0:14:38.000000 --> 0:14:39.720000 traffic comes in. 0:14:39.720000 --> 0:14:42.060000 Wouldn't it be cool if we could do that? 0:14:42.060000 --> 0:14:47.400000 Yes we can and that leads us into the next slide which is weighted random 0:14:47.400000 --> 0:14:52.140000 early discard that's exactly what it does. 0:14:52.140000 --> 0:14:56.960000 So with rated weighted random or I'll say red with red you still define 0:14:56.960000 --> 0:15:00.080000 your thresholds but that's exactly how it works. 0:15:00.080000 --> 0:15:05.400000 When you hit threshold number one you start randomly dropping packets 0:15:05.400000 --> 0:15:08.100000 that were mapped to that threshold. 0:15:08.100000 --> 0:15:15.900000 So threshold number one was set to 40% and it applied to packets with 0:15:15.900000 --> 0:15:20.880000 a precedence of zero through four. 0:15:20.880000 --> 0:15:26.200000 Then that means if you reach that threshold you're going to start randomly 0:15:26.200000 --> 0:15:28.700000 dropping some of those packets. 0:15:28.700000 --> 0:15:33.200000 Now it gets very very complex as far as what do you mean by random is 0:15:33.200000 --> 0:15:35.740000 it one out of every ten one out of every fifty. 0:15:35.740000 --> 0:15:39.540000 That is something that you can control but we're not going to get into 0:15:39.540000 --> 0:15:42.960000 that just for the purposes of illustration let's just pick a number and 0:15:42.960000 --> 0:15:48.060000 say one out of every ten packets is dropped. 0:15:48.060000 --> 0:15:57.900000 And then you set a second threshold threshold two maybe that's 80% and 0:15:57.900000 --> 0:16:03.380000 that maps to IP precedence values of five through seven. 0:16:03.380000 --> 0:16:09.220000 And so the way this works is that once we hit threshold number so from 0:16:09.220000 --> 0:16:16.020000 if we're at zero to 39% we don't drop anything. 0:16:16.020000 --> 0:16:18.780000 Everything is allowed into the queue at that point. 0:16:18.780000 --> 0:16:25.120000 Once I reach 40% now at 40% I start dropping one out of every ten packets 0:16:25.120000 --> 0:16:28.640000 that have a precedence value of zero through four. 0:16:28.640000 --> 0:16:35.320000 Now if the queue continues to grow and gets to 45%, 50%, then this rate 0:16:35.320000 --> 0:16:37.600000 of drop increases. 0:16:37.600000 --> 0:16:41.560000 Now it might start dropping one out of every five and then one out of 0:16:41.560000 --> 0:16:47.800000 every three. Once I get to threshold number two this stuff gets dropped 0:16:47.800000 --> 0:16:55.600000 into 100%. So if my queue reaches 80 % depth at that point no precedence 0:16:55.600000 --> 0:16:59.960000 values of zero through four are allowed into the queue anymore. 0:16:59.960000 --> 0:17:05.980000 At that point now I start dropping one out of every ten packets that map 0:17:05.980000 --> 0:17:10.280000 to a threshold that map to five and sixes and sevens. 0:17:10.280000 --> 0:17:18.760000 And the rate of drop of these starts to increase if I climb above 80%. 0:17:18.760000 --> 0:17:25.560000 So that is how weighted random early discard works. 0:17:25.560000 --> 0:17:30.380000 And that concludes this video on queue based congestion avoidance.