WEBVTT 1 00:00.000 --> 00:04.560 Well, queuing is a very foundational topic when it comes to quality of service. 2 00:04.560 --> 00:08.370 So let's take a moment to make sure we've got all of this down before moving on 3 00:08.370 --> 00:08.680 . 4 00:08.680 --> 00:12.720 First up, how many queues are supported by each of the following methods? 5 00:12.720 --> 00:15.080 So let's just think through what all of these are. 6 00:15.080 --> 00:19.300 So weighted fare queuing, this is where all of the traffic flows get mapped 7 00:19.300 --> 00:20.240 automatically 8 00:20.240 --> 00:22.320 to a different queue. 9 00:22.320 --> 00:26.680 And so that's going to be the largest number, which is 4096. 10 00:26.680 --> 00:30.320 Safety queuing is the one that we have those strict priority queues already WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:26.680 --> 00:30.320 Safety queuing is the one that we have those strict priority queues already 11 00:30.320 --> 00:30.920 built. 12 00:30.920 --> 00:34.120 They're the high, medium, normal and low. 13 00:34.120 --> 00:36.600 And so there's only four of those. 14 00:36.600 --> 00:40.360 CBW FQ low latency queuing that supports up to 256. 15 00:40.360 --> 00:44.740 Again, it's platform dependent, but we do support up to that much on certain 16 00:44.740 --> 00:45.720 platforms, 17 00:45.720 --> 00:50.200 custom queuing that will give us 16 different queue options. 18 00:50.200 --> 00:53.080 And first and first out, that is just a single one. 19 00:53.080 --> 00:57.540 So that is the how all these different queuing mechanisms come together and 20 00:57.540 --> 00:58.560 understanding 21 00:58.560 --> 01:03.280 that will help to make sure that we understand how the queues work. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:58.560 --> 01:03.280 that will help to make sure that we understand how the queues work. 22 01:03.280 --> 01:05.280 Now what does queuing enable for network traffic? 23 01:05.280 --> 01:10.160 Again, this is driving home the point of what we're trying to accomplish here. 24 01:10.160 --> 01:14.050 If we think back to the conveyor belt analogy, if I just have a single stack of 25 01:14.050 --> 01:14.760 boxes, I'm 26 01:14.760 --> 01:18.840 just going to grab the first box that's there and chuck it onto the conveyor 27 01:18.840 --> 01:19.400 belt. 28 01:19.400 --> 01:22.360 And so that's the concept of that first and first out. 29 01:22.360 --> 01:26.320 So we could say, hey, if there's a priority box somewhere in that stack, then 30 01:26.320 --> 01:26.920 you should 31 01:26.920 --> 01:28.160 go get that. 32 01:28.160 --> 01:31.480 But how am I supposed to know where that is and how am I supposed to know it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:28.160 --> 01:31.480 But how am I supposed to know where that is and how am I supposed to know it's 33 01:31.480 --> 01:31.760 even 34 01:31.760 --> 01:32.760 there? 35 01:32.760 --> 01:36.830 Well, what I can do is I can create multiple queues that allows me to see very 36 01:36.830 --> 01:37.360 clearly 37 01:37.360 --> 01:42.400 what is in each level of priority, whether that's just one priority type of 38 01:42.400 --> 01:43.000 queue or 39 01:43.000 --> 01:47.200 whether we have lots of different traffic classes like we do with networking. 40 01:47.200 --> 01:51.720 And so the idea here is not to send more packets because we can't do that. 41 01:51.720 --> 01:53.360 We can't increase our bandwidth. 42 01:53.360 --> 01:55.920 Our guarantee traffic is never dropped. 43 01:55.920 --> 02:01.120 But what we can do is we can now send one packet over another. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 43 01:55.920 --> 02:01.120 But what we can do is we can now send one packet over another. 44 02:01.120 --> 02:05.050 And we don't have that capability with first and first out where we just have 45 02:05.050 --> 02:05.600 to grab the 46 02:05.600 --> 02:06.920 next packet. 47 02:06.920 --> 02:11.510 Now why isn't the low latency queuing mechanism built on strict priority que 48 02:11.510 --> 02:12.000 uing? 49 02:12.000 --> 02:15.040 Why do we have that bandwidth limit in place? 50 02:15.040 --> 02:19.160 Remember, this is all about the concept of traffic starvation. 51 02:19.160 --> 02:23.120 We want to prevent starving non priority traffic, whether that's a misconfig 52 02:23.120 --> 02:24.000 uration because 53 02:24.000 --> 02:28.930 oops, I put something that's a very large traffic flow into a queue that now 54 02:28.930 --> 02:29.640 has strict 55 02:29.640 --> 02:30.720 priority. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 55 02:29.640 --> 02:30.720 priority. 56 02:30.720 --> 02:35.660 Or if we just have a bunch of voice traffic all of a sudden, we don't want that 57 02:35.660 --> 02:36.240 to make 58 02:36.240 --> 02:39.640 it so nobody else can access the network. 59 02:39.640 --> 02:43.320 And so it does seem a little bit backwards to say, oh yeah, we care so much 60 02:43.320 --> 02:44.040 about voice 61 02:44.040 --> 02:45.280 over IP. 62 02:45.280 --> 02:49.640 But in some cases we do want it not to be prioritized, but it does make sense 63 02:49.640 --> 02:50.080 when we 64 02:50.080 --> 02:54.060 think about it from a starvation perspective, which is why we don't want to use 65 02:54.060 --> 02:54.640 priority 66 02:54.640 --> 02:58.600 queuing like we talked about with those four strict priority queues. 67 02:58.600 --> 03:01.200 And yet we do need that priority mechanism in place. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 67 02:58.600 --> 03:01.200 And yet we do need that priority mechanism in place. 68 03:01.200 --> 03:05.000 We just need to make sure that it can't starve other traffic flows. 69 03:05.000 --> 03:10.180 So that is again, a foundational set of topics here talking about queuing the 70 03:10.180 --> 03:10.720 creation of 71 03:10.720 --> 03:15.640 multiple queues, controlling policy is going to require us to have different 72 03:15.640 --> 03:16.280 queues so 73 03:16.280 --> 03:20.360 that we can service packets in the order that we want to service them in. 74 03:20.360 --> 03:23.520 I hope this has been informative for you and I'd like to thank you for viewing.