WEBVTT 1 00:00.000 --> 00:04.620 In order to best understand how our modern queuing mechanisms work, it's good 2 00:04.620 --> 00:05.320 to understand 3 00:05.320 --> 00:07.120 where we came from. 4 00:07.120 --> 00:10.480 And as part of this, we want to introduce a very important concept that we will 5 00:10.480 --> 00:10.800 carry 6 00:10.800 --> 00:14.440 forward, which is known as a priority queue. 7 00:14.440 --> 00:21.880 But first of all, let's talk about the concept of first in, first out. 8 00:21.880 --> 00:26.240 Otherwise known as FIFO. 9 00:26.240 --> 00:30.930 First in first out is that queuing mechanism that essentially means that we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:26.240 --> 00:30.930 First in first out is that queuing mechanism that essentially means that we're 10 00:30.930 --> 00:31.520 doing no 11 00:31.520 --> 00:34.480 queuing, which is kind of funny. 12 00:34.480 --> 00:40.400 But it is the default setting on a Cisco network device interface. 13 00:40.400 --> 00:47.000 And essentially what it's saying is that we're going to have a single queue. 14 00:47.000 --> 00:51.600 First in first out simply means that the first packet to arrive is going to be 15 00:51.600 --> 00:52.440 the first 16 00:52.440 --> 00:54.560 packet that is sent. 17 00:54.560 --> 00:55.560 Which makes sense. 18 00:55.560 --> 01:02.400 If I have a queue or a buffer that is lined up like this, packet one arrives. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 18 00:55.560 --> 01:02.400 If I have a queue or a buffer that is lined up like this, packet one arrives. 19 01:02.400 --> 01:06.340 Well the scheduler, if we want to call it that at this point, the process 20 01:06.340 --> 01:07.120 responsible 21 01:07.120 --> 01:14.560 for sending the packets is going to start sending packet one out the egress 22 01:14.560 --> 01:16.040 interface. 23 01:16.040 --> 01:20.720 While packet one is being sent, three more packets arrive. 24 01:20.720 --> 01:24.360 And so these are packets two, three and four. 25 01:24.360 --> 01:29.300 And so as we see here, what we're doing is we're creating this queue of packets 26 01:29.300 --> 01:29.680 that 27 01:29.680 --> 01:33.320 get to be sent out in the order in which they arrived. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 27 01:29.680 --> 01:33.320 get to be sent out in the order in which they arrived. 28 01:33.320 --> 01:37.860 So after we've properly sent out packet number one, we're going to start 29 01:37.860 --> 01:39.160 sending out packet 30 01:39.160 --> 01:43.600 number two, and then we'll move to packet three and packet four and so on and 31 01:43.600 --> 01:44.440 so forth. 32 01:44.440 --> 01:47.320 First in first out is again the default setting. 33 01:47.320 --> 01:52.760 And it gives us absolutely no control for QOS. 34 01:52.760 --> 01:55.040 This is what we're trying to avoid. 35 01:55.040 --> 02:00.100 For example, what if packet number four here, that this is a voice over IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 35 01:55.040 --> 02:00.100 For example, what if packet number four here, that this is a voice over IP 36 02:00.100 --> 02:00.960 packet. 37 02:00.960 --> 02:05.720 And meanwhile packets one, two and three, these are all 1500 byte bulk traffic 38 02:05.720 --> 02:06.720 operations. 39 02:06.720 --> 02:08.120 Very low priority. 40 02:08.120 --> 02:12.280 It's going to take a while relatively to send 1500 bytes. 41 02:12.280 --> 02:15.640 And so this voice over IP packet is just going to have to sit in the back of 42 02:15.640 --> 02:16.640 the queue waiting 43 02:16.640 --> 02:18.080 its turn. 44 02:18.080 --> 02:23.330 So we want to avoid that and Cisco started creating some options for how to 45 02:23.330 --> 02:24.600 create multiple 46 02:24.600 --> 02:25.700 queues. 47 02:25.700 --> 02:36.200 The first option is known as custom queuing, which can be abbreviated as CQ. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 47 02:25.700 --> 02:36.200 The first option is known as custom queuing, which can be abbreviated as CQ. 48 02:36.200 --> 02:41.640 Custom queuing was created by Cisco and it leverages a basic form of scheduling 49 02:41.640 --> 02:42.160 known 50 02:42.160 --> 02:46.800 as weighted round robin or WR. 51 02:46.800 --> 02:55.000 Weight round robin is going to be used across 16 different queues. 52 02:55.000 --> 03:01.210 And the 16 queues are going to give us some basic control over our ability to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 02:55.000 --> 03:01.210 And the 16 queues are going to give us some basic control over our ability to 53 03:01.210 --> 03:02.840 assign traffic. 54 03:02.840 --> 03:06.800 So very basic level of control. 55 03:06.800 --> 03:11.840 And it's going to be based primarily on IP precedence. 56 03:11.840 --> 03:15.960 Now we've already said that we're not really using IP precedence anymore. 57 03:15.960 --> 03:21.040 And we're really not using custom queuing in modern networks either. 58 03:21.040 --> 03:24.240 So we don't expect to see much in the way of custom queuing these days. 59 03:24.240 --> 03:29.620 There's really not a huge advantage to deploying it compared to some of our 60 03:29.620 --> 03:31.000 better options. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 60 03:29.620 --> 03:31.000 better options. 61 03:31.000 --> 03:35.550 But the primary way this worked was we'd line our queues up here and we would 62 03:35.550 --> 03:36.240 actually 63 03:36.240 --> 03:41.040 assigned a byte count to each queue. 64 03:41.040 --> 03:47.590 This byte count ensured that different traffic flows would actually get to be 65 03:47.590 --> 03:48.480 serviced rather 66 03:48.480 --> 03:50.880 than just waiting their turn. 67 03:50.880 --> 03:54.360 And so a certain amount of bytes would get sent out. 68 03:54.360 --> 03:58.120 Let's say it's just, I don't know, let's just say it's four kilobytes or 69 03:58.120 --> 03:59.080 something like 70 03:59.080 --> 04:00.080 that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 03:59.080 --> 04:00.080 that. 71 04:00.080 --> 04:03.840 So we send four kilobytes of data and then we move on to the next queue. 72 04:03.840 --> 04:07.240 And so the next queue gets two kilobytes of data. 73 04:07.240 --> 04:14.240 We send that much data and then we go to the next queue and so on and so forth. 74 04:14.240 --> 04:19.340 And so based on the fact that we can sort our traffic by IP precedence, we can 75 04:19.340 --> 04:20.320 effectively 76 04:20.320 --> 04:24.620 put our voice over IP packets into one of these queues and that will ensure 77 04:24.620 --> 04:25.280 that they 78 04:25.280 --> 04:29.520 do get sent fairly, at least a little bit more fairly. 79 04:29.520 --> 04:33.980 The problem with custom queuing as much as anything is that we don't actually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 04:29.520 --> 04:33.980 The problem with custom queuing as much as anything is that we don't actually 80 04:33.980 --> 04:34.360 get to 81 04:34.360 --> 04:38.520 say that, hey, a voice packet arrived, we should send it immediately. 82 04:38.520 --> 04:41.670 It's still going to have to wait its turn, but at least it doesn't go into the 83 04:41.670 --> 04:42.160 back of 84 04:42.160 --> 04:43.160 the queue. 85 04:43.160 --> 04:46.700 If there's a bunch of packets lined up in the standard queue here, voice over 86 04:46.700 --> 04:47.040 IP can 87 04:47.040 --> 04:51.510 go somewhere else so that once that standard queue has sent so much traffic, 88 04:51.510 --> 04:52.320 now the voice 89 04:52.320 --> 04:55.160 over IP packets can start to send. 90 04:55.160 --> 04:59.530 So better than nothing, but again, in the modern network, we typically don't 91 04:59.530 --> 05:00.120 see custom WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 91 04:59.530 --> 05:00.120 see custom 92 05:00.120 --> 05:02.160 queuing deployed anymore. 93 05:02.160 --> 05:07.730 Now, our next mechanism is known as priority queuing and priority queuing set 94 05:07.730 --> 05:08.680 out to solve 95 05:08.680 --> 05:13.580 the problem that we just said that custom queuing didn't provide, which is to 96 05:13.580 --> 05:14.200 provide 97 05:14.200 --> 05:20.240 what we call strict priority to certain traffic flows. 98 05:20.240 --> 05:27.140 Strict priority simply means that if a packet arrives, it gets sent immediately 99 05:27.140 --> 05:27.440 . 100 05:27.440 --> 05:32.520 It is sent first before any other packet gets set. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 100 05:27.440 --> 05:32.520 It is sent first before any other packet gets set. 101 05:32.520 --> 05:36.810 So this is kind of interesting because essentially what we're saying here is, 102 05:36.810 --> 05:37.480 well, first of 103 05:37.480 --> 05:41.200 all, PQ gives us four queues. 104 05:41.200 --> 05:44.560 So remember, custom queuing gave us 16 queues. 105 05:44.560 --> 05:48.720 Priority queuing gives us four different queues. 106 05:48.720 --> 05:51.080 Now these queues are going to be sorted by priority. 107 05:51.080 --> 05:58.500 We have a high priority queue, a medium priority, normal priority, and then low 108 05:58.500 --> 05:59.800 priority. 109 05:59.800 --> 06:04.760 So the idea here is that while most of our traffic would go into the normal WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 05:59.800 --> 06:04.760 So the idea here is that while most of our traffic would go into the normal 110 06:04.760 --> 06:05.600 queue, we 111 06:05.600 --> 06:09.920 do have the ability to throw some traffic into the low priority queue. 112 06:09.920 --> 06:14.630 If we so desire, if there's traffic out there, we just truly don't care whether 113 06:14.630 --> 06:15.160 or not it 114 06:15.160 --> 06:17.000 actually ever makes it through. 115 06:17.000 --> 06:20.440 Now, here's the concept of the strict priority. 116 06:20.440 --> 06:25.020 Strict priority means, remember that if it arrives, it is sent first, but this 117 06:25.020 --> 06:25.640 is going 118 06:25.640 --> 06:34.240 to be relative to the priority level. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 118 06:25.640 --> 06:34.240 to be relative to the priority level. 119 06:34.240 --> 06:40.340 So what happens if a, let's just say we have a bunch of traffic in the normal, 120 06:40.340 --> 06:40.920 here, we'll 121 06:40.920 --> 06:41.920 draw like this. 122 06:41.920 --> 06:48.080 We have a bunch of traffic in the normal queue and in the low queue. 123 06:48.080 --> 06:51.130 So what's going to happen here, first of all, is that we're just going to be 124 06:51.130 --> 06:51.560 sending 125 06:51.560 --> 06:53.240 these normal packets. 126 06:53.240 --> 06:58.140 The low priority queue isn't going to send anything until normal is completely 127 06:58.140 --> 06:58.720 sent. 128 06:58.720 --> 07:02.200 But what happens if a couple of packets show up in the medium queue? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 128 06:58.720 --> 07:02.200 But what happens if a couple of packets show up in the medium queue? 129 07:02.200 --> 07:06.320 Well, now we're not going to service even the normal queue anymore. 130 07:06.320 --> 07:10.200 We're going to start servicing the medium queue until it's empty. 131 07:10.200 --> 07:13.720 And likewise, if packets start showing up in the high priority queue, which is, 132 07:13.720 --> 07:13.920 assuming 133 07:13.920 --> 07:18.430 that we'd place our voice over IP packets, well, now we're going to be sending 134 07:18.430 --> 07:18.800 packets 135 07:18.800 --> 07:24.050 from the high priority queue, not the medium, not the normal, and certainly not 136 07:24.050 --> 07:24.840 the low. 137 07:24.840 --> 07:26.920 This is a very interesting model. 138 07:26.920 --> 07:31.590 And it, again, introduces the concept of strict priority, meaning that one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 138 07:26.920 --> 07:31.590 And it, again, introduces the concept of strict priority, meaning that one 139 07:31.590 --> 07:32.800 queue has a strict 140 07:32.800 --> 07:37.090 priority over another, in our case, all of these have strict priority over 141 07:37.090 --> 07:37.920 those queues 142 07:37.920 --> 07:40.000 that are below them. 143 07:40.000 --> 07:44.330 But the problem with this mechanism, as great as it is from a priority 144 07:44.330 --> 07:45.600 perspective, our 145 07:45.600 --> 07:49.520 voice over IP packets are always getting sent the moment they show up. 146 07:49.520 --> 07:52.120 Maybe our video packets are in the medium queue. 147 07:52.120 --> 07:56.510 So they're getting a wonderful amount of attention, prioritization, and amount 148 07:56.510 --> 07:57.320 of bandwidth 149 07:57.320 --> 07:58.320 on the link. 150 07:58.320 --> 07:59.320 That's great. 151 07:59.320 --> 08:05.040 The problem that we see here is the concept of starvation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 151 07:59.320 --> 08:05.040 The problem that we see here is the concept of starvation. 152 08:05.040 --> 08:07.800 So we have created this problem. 153 08:07.800 --> 08:11.340 We've solved one problem, created another one, and we've introduced this 154 08:11.340 --> 08:12.200 concept of queue 155 08:12.200 --> 08:13.680 starvation. 156 08:13.680 --> 08:18.600 This low priority queue is very unlikely to ever get serviced. 157 08:18.600 --> 08:23.100 That's why in this model, low priority is really meant to be that scavenger 158 08:23.100 --> 08:23.680 class, like 159 08:23.680 --> 08:28.280 we said, which traffic that we don't care if it ever actually makes it through. 160 08:28.280 --> 08:31.680 So maybe we say, okay, that's fine then if we truly don't care whether it makes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 160 08:28.280 --> 08:31.680 So maybe we say, okay, that's fine then if we truly don't care whether it makes 161 08:31.680 --> 08:32.720 it through, 162 08:32.720 --> 08:35.400 then it's not a big deal if it never makes it through. 163 08:35.400 --> 08:40.370 Except what happens if we have so much traffic in our high and medium priority 164 08:40.370 --> 08:41.800 queues that 165 08:41.800 --> 08:46.240 we've just got a lot of video calls going and all of the bandwidth is being 166 08:46.240 --> 08:46.920 consumed 167 08:46.920 --> 08:48.840 by voice and video calls. 168 08:48.840 --> 08:50.800 Well, now look at our normal traffic. 169 08:50.800 --> 08:53.200 Our normal traffic is also getting starved. 170 08:53.200 --> 08:57.320 This isn't just a matter of our scavenger class getting starved. 171 08:57.320 --> 09:01.520 It's all of our normal internet operations, our downloads, just working with WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 171 08:57.320 --> 09:01.520 It's all of our normal internet operations, our downloads, just working with 172 09:01.520 --> 09:02.360 applications 173 09:02.360 --> 09:07.750 online, anything that doesn't fall into these categories up here is going to 174 09:07.750 --> 09:08.920 face potential 175 09:08.920 --> 09:10.520 queue starvation. 176 09:10.520 --> 09:16.560 And so priority queuing is also not really used very often if ever in modern 177 09:16.560 --> 09:18.280 networking. 178 09:18.280 --> 09:22.190 Instead, what we're going to do is we're going to take the concept of a strict 179 09:22.190 --> 09:22.800 priority 180 09:22.800 --> 09:28.710 queue, focus in on the idea of making priority queues work out in our favor and 181 09:28.710 --> 09:29.760 deploy those 182 09:29.760 --> 09:33.230 in a couple of different ways as we'll see coming up in the next video when we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 182 09:29.760 --> 09:33.230 in a couple of different ways as we'll see coming up in the next video when we 183 09:33.230 --> 09:33.720 explore 184 09:33.720 --> 09:36.280 what we do in the modern network. 185 09:36.280 --> 09:43.280 Now lastly, we do have the concept of weighted fair queuing. 186 09:43.280 --> 09:53.620 Weighted fair queuing, which can be abbreviated as WFQ, is a creation by Cisco 187 09:53.620 --> 09:55.000 again. 188 09:55.000 --> 10:00.960 The idea here is that we are going to create a massive number of queues WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 188 09:55.000 --> 10:00.960 The idea here is that we are going to create a massive number of queues 189 10:00.960 --> 10:02.720 automatically. 190 10:02.720 --> 10:10.280 So we're going to create up to 4096 auto generated queues. 191 10:10.280 --> 10:13.530 And the idea here is we're going to take every single traffic flow that comes 192 10:13.530 --> 10:14.040 through the 193 10:14.040 --> 10:20.120 network and we are going to place it into its own dedicated queue. 194 10:20.120 --> 10:21.120 Pretty fascinating. 195 10:21.120 --> 10:25.000 We're talking about 4096 on some platforms. 196 10:25.000 --> 10:29.600 That many different traffic flows can be placed into their own queue. 197 10:29.600 --> 10:34.210 And the idea of weighted fair queuing here, first of all, fair queuing, meaning WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 197 10:29.600 --> 10:34.210 And the idea of weighted fair queuing here, first of all, fair queuing, meaning 198 10:34.210 --> 10:34.880 that every 199 10:34.880 --> 10:40.980 single traffic or every single traffic flow is getting serviced fairly, meaning 200 10:40.980 --> 10:41.480 that if 201 10:41.480 --> 10:47.160 I've got, let's say, one, two, three different traffic flows, that I might have 202 10:47.160 --> 10:48.240 a bunch of 203 10:48.240 --> 10:50.880 packets lined up in one of the flows. 204 10:50.880 --> 10:54.970 But look at this, as packets come into this other flow, I'm going to take 205 10:54.970 --> 10:55.800 fairly from 206 10:55.800 --> 10:59.800 each individual queue and then I'm going to go back to the top. 207 10:59.800 --> 11:02.480 And that's the responsibility of the scheduler. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 207 10:59.800 --> 11:02.480 And that's the responsibility of the scheduler. 208 11:02.480 --> 11:07.810 So it's fair, but Cisco added a little bit of weighting into it, meaning that 209 11:07.810 --> 11:08.520 they're 210 11:08.520 --> 11:17.600 also going to prioritize low bandwidth flows. 211 11:17.600 --> 11:22.040 Now what major traffic type falls into the category of low bandwidth flows? 212 11:22.040 --> 11:24.880 Well, voiceover IP certainly does. 213 11:24.880 --> 11:30.130 So not only are we going to find that we're fairly balancing our traffic across WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 213 11:24.880 --> 11:30.130 So not only are we going to find that we're fairly balancing our traffic across 214 11:30.130 --> 11:30.880 multiple 215 11:30.880 --> 11:36.520 flows, but let's say this bottom flow happens to be voiceover IP traffic flow. 216 11:36.520 --> 11:40.180 Well, that's going to qualify as low bandwidth and it's going to get a little 217 11:40.180 --> 11:40.960 bit more love 218 11:40.960 --> 11:42.920 than the other queues. 219 11:42.920 --> 11:47.810 So what's wonderful about WFQ is it works really well from the perspective of 220 11:47.810 --> 11:48.680 just a 221 11:48.680 --> 11:54.280 very simple turn on a queuing mechanism and allow the system to do its thing. 222 11:54.280 --> 12:01.430 The problem once again that we have with both of these queuing mechanisms is no WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 222 11:54.280 --> 12:01.430 The problem once again that we have with both of these queuing mechanisms is no 223 12:01.430 --> 12:03.040 prioritization 224 12:03.040 --> 12:07.080 from the perspective that if a voiceover IP packet comes in, that it gets sent 225 12:07.080 --> 12:07.560 out. 226 12:07.560 --> 12:11.000 So really, we're talking about a strict priority concept. 227 12:11.000 --> 12:16.240 Yes, there is a weighted concept here, but it's not prioritization. 228 12:16.240 --> 12:20.480 It's not a priority queue that voiceover IP gets placed into. 229 12:20.480 --> 12:25.030 So at this point, this gives us a really good foundation for some of the 230 12:25.030 --> 12:26.240 struggles and trying 231 12:26.240 --> 12:30.380 to come up with some good queuing mechanisms in the early days of quality of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 231 12:26.240 --> 12:30.380 to come up with some good queuing mechanisms in the early days of quality of 232 12:30.380 --> 12:31.120 service. 233 12:31.120 --> 12:34.660 In the next video, we're going to see what exactly we do these days in our 234 12:34.660 --> 12:35.560 modern networks 235 12:35.560 --> 12:40.680 that solve the problems that are in here and don't create new problems by 236 12:40.680 --> 12:41.600 trying to solve 237 12:41.600 --> 12:42.680 some of those problems.