WEBVTT 1 00:00.000 --> 00:05.400 We need to address a problem that we have, which is that a buffer, which allows 2 00:05.400 --> 00:07.500 us to fill this up with packets. 3 00:07.500 --> 00:12.520 It's only so large. And so while we're trying to send the packet at the front 4 00:12.520 --> 00:16.000 of the buffer, or in our case, the queue, 5 00:16.000 --> 00:20.430 we might find that we're completely out of space in this queue. So keep in mind 6 00:20.430 --> 00:21.500 what we've said. 7 00:21.500 --> 00:27.370 A couple of key things here. First of all, QOS does not mean that there are no 8 00:27.370 --> 00:28.500 drops. 9 00:28.500 --> 00:35.030 So this is my does not equal sign here. Does not equal no drops. However, what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:28.500 --> 00:35.030 So this is my does not equal sign here. Does not equal no drops. However, what 10 00:35.030 --> 00:40.500 it does equal is that we can choose which packets to drop. 11 00:40.500 --> 00:47.090 We choose the drops. And this is a really good thing, because for example, if a 12 00:47.090 --> 00:51.500 packet shows up and it needs to go into this queue, 13 00:51.500 --> 00:57.800 well, we can actually decide in theory whether or not to drop that packet. But 14 00:57.800 --> 01:01.500 here's the catch. If I want to evaluate this packet, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 14 00:57.800 --> 01:01.500 here's the catch. If I want to evaluate this packet, 15 01:01.500 --> 01:05.610 let's say this is a priority packet, I want to decide whether to put it into 16 01:05.610 --> 01:09.500 that queue. If this queue is full, 17 01:09.500 --> 01:14.890 this means that this packet must be dropped. I don't have a choice. I can 18 01:14.890 --> 01:17.500 recognize that it's a priority packet, 19 01:17.500 --> 01:22.200 but if it's completely full, then it's just going to get dropped. And so when 20 01:22.200 --> 01:26.500 we're talking about we choose which packets get dropped, 21 01:26.500 --> 01:31.190 this key emphasis here that I want to make is on the word choose. We want to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 01:26.500 --> 01:31.190 this key emphasis here that I want to make is on the word choose. We want to 22 01:31.190 --> 01:36.500 maintain our choice. And so that's the goal of pretty much this entire skill 23 01:36.500 --> 01:43.850 is to understand that we want to maintain the choice over which packets we're 24 01:43.850 --> 01:46.500 going to drop. But unfortunately, 25 01:46.500 --> 01:50.200 maybe I should just say for better or worse, that's going to require us to 26 01:50.200 --> 01:54.500 think through situations that remove the choice from us. 27 01:54.500 --> 02:00.340 And therefore, we need to find out how to avoid those situations. So let's get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 27 01:54.500 --> 02:00.340 And therefore, we need to find out how to avoid those situations. So let's get 28 02:00.340 --> 02:04.500 back to thinking about things from a router or switch perspective. 29 02:04.500 --> 02:09.470 Let's just say we have a router here, and I've got my four different queues. 30 02:09.470 --> 02:14.500 And so this is really helpful because basically what we're saying now 31 02:14.500 --> 02:20.540 is that each individual queue has its own buffer size. And merely we should 32 02:20.540 --> 02:22.500 think of it as packet size or byte size. 33 02:22.500 --> 02:27.850 It just depends on how we want to define it. And so if I have, let's say, voice 34 02:27.850 --> 02:29.500 over IP up here in this queue, 35 02:29.500 --> 02:33.300 if I only have a couple of packets here, and meanwhile, my best effort down WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 35 02:29.500 --> 02:33.300 if I only have a couple of packets here, and meanwhile, my best effort down 36 02:33.300 --> 02:36.500 here with all of the other types of traffic, 37 02:36.500 --> 02:41.210 maybe we've got a few in here for whatever these queues are doing as well. But 38 02:41.210 --> 02:46.970 if this is completely full down here and a priority packet arrives onto this 39 02:46.970 --> 02:47.500 device, 40 02:47.500 --> 02:51.930 and it needs to get sent out to this egress interface. So remember, we're 41 02:51.930 --> 02:54.500 talking about sending it out an interface. 42 02:54.500 --> 02:59.450 So this packet arrives in its priority. It's a voice over IP packet. Well, this 43 02:59.450 --> 03:02.500 queue down here is full, but the queue up here is not. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 43 02:59.450 --> 03:02.500 queue down here is full, but the queue up here is not. 44 03:02.500 --> 03:06.970 We've got all of these spots available inside the voice over IP queue. So just 45 03:06.970 --> 03:12.900 having multiple queues is going to be really helpful to making sure that I don 46 03:12.900 --> 03:15.500 't have to drop packets of a particular priority. 47 03:15.500 --> 03:21.810 Now, if I happen to fill up this voice over IP queue, and now it is completely 48 03:21.810 --> 03:24.500 full, well, at that point, we don't have a choice. 49 03:24.500 --> 03:28.810 We are going to have to drop this packet. And so if those are our two 50 03:28.810 --> 03:33.650 conversation points, which is one, we want to maintain as much choice as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 50 03:28.810 --> 03:33.650 conversation points, which is one, we want to maintain as much choice as 51 03:33.650 --> 03:34.500 possible. 52 03:34.500 --> 03:38.840 But number two, if it fills up, it's going to be dropped on the individual 53 03:38.840 --> 03:41.500 queues. Is the conversation done? 54 03:41.500 --> 03:45.840 Is it just a matter of, hey, if it's empty, if we have space, we're good. If we 55 03:45.840 --> 03:49.500 don't have space, we're not in good shape anymore. 56 03:49.500 --> 03:53.520 And the answer is no, there's going to be a little bit more to this 57 03:53.520 --> 03:54.500 conversation. 58 03:54.500 --> 03:59.370 Because the reality is that while we might have a priority queue up here with 59 03:59.370 --> 04:03.500 voice over IP, that is maybe checking for markings EF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 59 03:59.370 --> 04:03.500 voice over IP, that is maybe checking for markings EF. 60 04:03.500 --> 04:07.680 And then we have the best effort, which is sort of the catch all, but we'll say 61 04:07.680 --> 04:09.500 also that it's a label of zero. 62 04:09.500 --> 04:13.500 This is kind of all or nothing for these two queues. 63 04:13.500 --> 04:17.520 Either a packet is voice over IP and it goes in or it's not voice over IP and 64 04:17.520 --> 04:22.500 it doesn't go into the top queue and same with down here with the best effort. 65 04:22.500 --> 04:27.360 But what about these queues in the middle? We might find that we have a high 66 04:27.360 --> 04:32.500 priority queue in here and we're going to use that assured forwarding for. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 66 04:27.360 --> 04:32.500 priority queue in here and we're going to use that assured forwarding for. 67 04:32.500 --> 04:37.640 And let's say we map all of the fours in here. So for one, for two, for three, 68 04:37.640 --> 04:39.500 we'll just say for X here. 69 04:39.500 --> 04:44.990 So this means, actually, let's just draw those out because now we can see that 70 04:44.990 --> 04:48.500 we've got AF41, AF42 and AF43. 71 04:48.500 --> 04:55.530 These are three different priority levels that are all going into the same 72 04:55.530 --> 04:56.500 queue. 73 04:56.500 --> 05:00.500 So now what can we do? What does this mean for us? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 73 04:56.500 --> 05:00.500 So now what can we do? What does this mean for us? 74 05:00.500 --> 05:06.500 Well, now if we have a situation where one of these packets shows up and it's, 75 05:06.500 --> 05:11.600 we'll just say four packet here assured forwarding for its 4, 1, 4, 2, 4, 3, 76 05:11.600 --> 05:13.500 and it's supposed to go into this queue. 77 05:13.500 --> 05:18.690 If this queue is now completely filled up, we try to put it in there, it's 78 05:18.690 --> 05:20.500 going to get dropped. 79 05:20.500 --> 05:23.840 And if all of these were just the same priority value, that wouldn't be a 80 05:23.840 --> 05:24.500 problem. 81 05:24.500 --> 05:30.640 But what if we are ordering it in order of importance like this, where AF41 is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 05:24.500 --> 05:30.640 But what if we are ordering it in order of importance like this, where AF41 is 82 05:30.640 --> 05:35.500 the number one most important traffic inside of that queue. 83 05:35.500 --> 05:40.820 And now this is a AF41 packet that just arrived and we have a ton of 43s in 84 05:40.820 --> 05:43.500 here. We're filled up with 43s. 85 05:43.500 --> 05:49.820 Now we see the problem that I have this relatively, this is relative in this 86 05:49.820 --> 05:50.500 case, 87 05:50.500 --> 05:54.500 relative to the three different tags that could go into that queue. 88 05:54.500 --> 05:58.930 This is the most important of those three, and yet I'm still going to have to 89 05:58.930 --> 06:01.500 drop it because the queue is full. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 05:58.930 --> 06:01.500 drop it because the queue is full. 90 06:01.500 --> 06:06.680 If the queue is full, even if it's filled with lower priority packets, I'm 91 06:06.680 --> 06:10.750 still going to have to drop this relatively high priority packet that just 92 06:10.750 --> 06:11.500 arrived. 93 06:11.500 --> 06:15.500 This is the problem that we want to try to avoid. 94 06:15.500 --> 06:20.990 So now we see an intersection here of what we're trying to accomplish, which is 95 06:20.990 --> 06:25.920 we want to maintain the choice of our drops, and yet we have a situation here 96 06:25.920 --> 06:30.020 where if it's full, this means that we automatically are going to drop the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 96 06:25.920 --> 06:30.020 where if it's full, this means that we automatically are going to drop the 97 06:30.020 --> 06:30.500 packet. 98 06:30.500 --> 06:36.190 So more or less we're saying that this situation is the problem, and therefore 99 06:36.190 --> 06:37.500 we can draw a conclusion. 100 06:37.500 --> 06:44.610 And our conclusion is simply that we want to make sure that a queue is never 101 06:44.610 --> 06:45.500 full. 102 06:45.500 --> 06:48.500 This is what we're going to try to accomplish. 103 06:48.500 --> 06:54.500 And even though that seems like a lofty goal, there is a way to make it happen. 104 06:54.500 --> 07:00.030 Now, unfortunately, it's not going to be just make it so the queue has an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 104 06:54.500 --> 07:00.030 Now, unfortunately, it's not going to be just make it so the queue has an 105 07:00.030 --> 07:01.500 infinite size. 106 07:01.500 --> 07:07.140 We don't want to just fill up the queue with more and more packets. In fact, if 107 07:07.140 --> 07:11.050 the packet or if the queue is so full of low priority traffic, that doesn't 108 07:11.050 --> 07:15.710 help our higher priority traffic anyways, and not to mention the fact that we 109 07:15.710 --> 07:17.500 do have system resources involved. 110 07:17.500 --> 07:21.500 So we can't just increase the size of the queue. 111 07:21.500 --> 07:27.500 That's not necessarily an option, nor would it be necessarily a desirable one. 112 07:27.500 --> 07:33.010 So we want to talk about the queue never being full, but before we do, there's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 112 07:27.500 --> 07:33.010 So we want to talk about the queue never being full, but before we do, there's 113 07:33.010 --> 07:37.750 another problem that we have to address in order to see really how the solution 114 07:37.750 --> 07:39.500 is going to come together. 115 07:39.500 --> 07:51.500 So problem number one here, problem one, is that a full queue equals no choice. 116 07:51.500 --> 07:55.880 A packets are just going to drop when they show up. But we do have another 117 07:55.880 --> 07:57.500 problem in all of this. 118 07:57.500 --> 08:01.500 And this has to do with TCP behavior. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 118 07:57.500 --> 08:01.500 And this has to do with TCP behavior. 119 08:01.500 --> 08:07.530 So think about TCP, the transmission control protocol, one of the most common 120 08:07.530 --> 08:12.500 layer for protocols on the Internet and in all of our networks. 121 08:12.500 --> 08:22.500 TCP is a wonderful protocol because TCP adjusts itself based on congestion. 122 08:22.500 --> 08:29.330 The fact that it adjusts itself means that if congestion is high, for high 123 08:29.330 --> 08:37.500 congestion, we're going to throttle down our transmissions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 123 08:29.330 --> 08:37.500 congestion, we're going to throttle down our transmissions. 124 08:37.500 --> 08:40.690 Where you accomplish this in a number of different ways with TCP, but 125 08:40.690 --> 08:45.100 ultimately what we're saying here is if I have a computer and I'm setting a 126 08:45.100 --> 08:49.980 bunch of TCP information and a couple of these packets don't make it through, 127 08:49.980 --> 08:53.690 TCP says, "Ah, the packets didn't make it through, therefore there must be 128 08:53.690 --> 08:54.500 congestion." 129 08:54.500 --> 08:59.110 So I'm actually going to slow down my transmissions in order to make sure that 130 08:59.110 --> 09:02.500 I'm not contributing to the problem of congestion. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 130 08:59.110 --> 09:02.500 I'm not contributing to the problem of congestion. 131 09:02.500 --> 09:08.500 So that sounds good. It really is a neat aspect to using TCP on our networks. 132 09:08.500 --> 09:13.500 Here's the problem. What if I have thousands of hosts? 133 09:13.500 --> 09:18.220 And these hosts are all sending traffic out onto the network and a lot of them 134 09:18.220 --> 09:22.720 converge through maybe a single network device, not a terribly uncommon 135 09:22.720 --> 09:23.500 situation. 136 09:23.500 --> 09:29.050 And so we've got this connection upstream to the Internet maybe or elsewhere in 137 09:29.050 --> 09:34.160 the network and there's congestion on this link so that we're constantly having WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 137 09:29.050 --> 09:34.160 the network and there's congestion on this link so that we're constantly having 138 09:34.160 --> 09:36.500 drops on this link because of congestion. 139 09:36.500 --> 09:41.870 Well, what do these 1000 hosts do? Assuming a random distribution of dropped 140 09:41.870 --> 09:46.930 packets, there's a possibility that all of them sense the congestion and so 141 09:46.930 --> 09:50.500 they all throttle down their transmissions. 142 09:50.500 --> 09:54.110 Well, guess what happens to the throttle down of transmissions? It means that 143 09:54.110 --> 09:59.390 this congestion goes away, which is the goal, except usually we throttle down 144 09:59.390 --> 10:04.220 so much that not only do we get rid of the congestion, it's now very clear link WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 144 09:59.390 --> 10:04.220 so much that not only do we get rid of the congestion, it's now very clear link 145 10:04.220 --> 10:04.500 . 146 10:04.500 --> 10:08.920 Well, what happens at that point is all of the hosts ramp back up and now we 147 10:08.920 --> 10:12.500 start to see drops again and we end up in this infinite cycle. 148 10:12.500 --> 10:17.180 So what happens is our hosts ramp up, ramp up, ramp up their transmission and 149 10:17.180 --> 10:21.730 because of congestion, they all of a sudden drop the amount of packets that 150 10:21.730 --> 10:23.500 they're transmitting. 151 10:23.500 --> 10:27.690 And then we see all of these hosts ramp up, ramp up, ramp up and we hit a 152 10:27.690 --> 10:30.500 congestion point and it all drops again. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 10:27.690 --> 10:30.500 congestion point and it all drops again. 153 10:30.500 --> 10:35.580 And so if the link bandwidth is roughly here, let's say, where we kind of spike 154 10:35.580 --> 10:40.800 to the max and we start having all kinds of network drops, we see that this is 155 10:40.800 --> 10:45.500 not a very efficient way to send traffic in our environment. 156 10:45.500 --> 10:51.350 We have a lot of wasted bandwidth in here and we'd really rather somehow smooth 157 10:51.350 --> 10:52.500 this curve. 158 10:52.500 --> 11:00.500 There's a word for this phenomenon. It is known as TCP global synchronization. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 158 10:52.500 --> 11:00.500 There's a word for this phenomenon. It is known as TCP global synchronization. 159 11:00.500 --> 11:05.830 And TCP global synchronization is caused by this problem that we're talking 160 11:05.830 --> 11:10.890 about, which is that if a queue is full, then we are going to just start 161 11:10.890 --> 11:12.500 dropping packets. 162 11:12.500 --> 11:17.690 That's no good for anybody. If we are just dropping packets when the queues are 163 11:17.690 --> 11:22.500 full and we're not dropping any packets when the queues are not full. 164 11:22.500 --> 11:27.820 So what are we going to do about it? Well, let's get back to talking about our 165 11:27.820 --> 11:28.500 solution. 166 11:28.500 --> 11:33.420 We want the queue to make sure we want to make sure the queue is never full. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 166 11:28.500 --> 11:33.420 We want the queue to make sure we want to make sure the queue is never full. So 167 11:33.420 --> 11:38.320 that number one, we have a choice over which packets are getting dropped in 168 11:38.320 --> 11:39.500 number two. 169 11:39.500 --> 11:47.210 We want to avoid this TCP global synchronization. The solution to both of these 170 11:47.210 --> 11:52.500 problems is congestion avoidance. 171 11:52.500 --> 11:57.820 Say, all right, well, let's just avoid the congestion or congestion. All right, 172 11:57.820 --> 12:00.500 well, that's great. How do we go about doing it? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 172 11:57.820 --> 12:00.500 well, that's great. How do we go about doing it? 173 12:00.500 --> 12:05.320 Okay, well, that's an interesting question and certainly one we're going to be 174 12:05.320 --> 12:08.500 talking about. But here's the answer. Here's what we're going to do. 175 12:08.500 --> 12:14.500 We are going to preemptively drop packets. 176 12:14.500 --> 12:21.030 We want to actually choose to drop certain packets as they come in. So as the 177 12:21.030 --> 12:24.500 queue starts to fill up, I'm just going to start dropping packets. 178 12:24.500 --> 12:29.260 Namely, here's my queue. It starts to fill up. And around this time, if a 179 12:29.260 --> 12:34.510 packet shows up, especially if it's a lower priority, there's a percent chance WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 12:29.260 --> 12:34.510 packet shows up, especially if it's a lower priority, there's a percent chance 180 12:34.510 --> 12:38.500 that I'm going to say, you know what, there's a lot of space here in the queue. 181 12:38.500 --> 12:43.550 I could easily slot this into the queue. But remember, we want to avoid a full 182 12:43.550 --> 12:46.500 queue. So I'm going to drop that packet. 183 12:46.500 --> 12:51.030 Now, hopefully, I'm paying attention to my relative priorities. And I'm saying 184 12:51.030 --> 12:54.500 that you're a lower priority level. And so I'm going to go ahead and drop you. 185 12:54.500 --> 12:59.650 I would never drop an AF-41, for example, but I might drop an AF-43 when it 186 12:59.650 --> 13:05.490 comes in. And so as the queue starts to fill up more and more, now let's say WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 186 12:59.650 --> 13:05.490 comes in. And so as the queue starts to fill up more and more, now let's say 187 13:05.490 --> 13:07.500 that we're getting closer to being a full packet. 188 13:07.500 --> 13:13.610 This percentage of drop is going to go up. And we might even get to a point 189 13:13.610 --> 13:19.300 where we're dropping fully all AF-42s and AF-43s, because the limited amount of 190 13:19.300 --> 13:26.980 space that's left, we really want to reserve this for the best priority, which 191 13:26.980 --> 13:29.500 is AF-41 in our example. 192 13:29.500 --> 13:34.700 And so if a 42 shows up, we drop it. If a 43 shows up, we drop it. The queue is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 192 13:29.500 --> 13:34.700 And so if a 42 shows up, we drop it. If a 43 shows up, we drop it. The queue is 193 13:34.700 --> 13:39.790 not full. But what we're trying to prevent is this queue filling up and making 194 13:39.790 --> 13:43.500 it so we have no choice over which packets get dropped. 195 13:43.500 --> 13:50.390 By doing this slowly over time, we actually find that we ramp up this TCP 196 13:50.390 --> 13:55.640 transmission rate, and it makes it so it doesn't constantly sharply bounce off, 197 13:55.640 --> 13:58.500 because it's no longer situation where here's where the queue is. 198 13:58.500 --> 14:03.090 Here's where the queue is empty the whole time. And then the moment the queue WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 198 13:58.500 --> 14:03.090 Here's where the queue is empty the whole time. And then the moment the queue 199 14:03.090 --> 14:08.500 gets full, we drop down. Instead, because we control the dropping of packets, 200 14:08.500 --> 14:12.720 it smooths out the curve and makes it a much more efficient means of consuming 201 14:12.720 --> 14:14.500 that interface bandwidth. 202 14:14.500 --> 14:18.480 So from here, we're going to talk about the different techniques that allow us 203 14:18.480 --> 14:22.850 to perform this congestion avoidance conversation. But we needed to start with 204 14:22.850 --> 14:27.550 understanding the problem. We have two problems here. They essentially both rev 205 14:27.550 --> 14:30.500 olve around the concept of a queue being full. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 205 14:27.550 --> 14:30.500 olve around the concept of a queue being full. 206 14:30.500 --> 14:34.770 It creates these bad situations. It creates the situation of us having no 207 14:34.770 --> 14:40.660 choice. It creates this TCP global synchronization problem. And as a result, we 208 14:40.660 --> 14:43.500 need to ensure that the queue is never full. 209 14:43.500 --> 14:48.500 So that we can maintain our choice and smooth out TCP behavior.