WEBVTT 1 00:00.000 --> 00:06.940 Well Cisco created a method of queuing known as class-based weighted fair que 2 00:06.940 --> 00:07.640 uing, 3 00:07.640 --> 00:12.600 which it sounds familiar, WFQ, we just talked about that. So overall we can 4 00:12.600 --> 00:20.600 refer to this as CBWFQ. The idea here is now to continue to do fair amounts of 5 00:20.600 --> 00:25.120 queuing but weighted and the waiting is going to be based on the traffic class. 6 00:25.120 --> 00:32.160 This allows us to define almost any number of queues. Ultimately it's up to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 6 00:25.120 --> 00:32.160 This allows us to define almost any number of queues. Ultimately it's up to 7 00:32.160 --> 00:37.480 256 queues on some platforms but again keep in mind that this is from a 8 00:37.480 --> 00:42.160 software perspective so routers can go that high. A lot of more hardware-based 9 00:42.160 --> 00:46.800 platforms like switches might have four or eight queues at the most that we can 10 00:46.800 --> 00:51.800 configure here. But the idea is this we have total control over the queues that 11 00:51.800 --> 00:56.640 we're creating. We don't have to worry about the high and low priority queues 12 00:56.640 --> 01:01.800 and the automatic flow-based queues, all of those queues that lack control, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 12 00:56.640 --> 01:01.800 and the automatic flow-based queues, all of those queues that lack control, we 13 01:01.800 --> 01:02.160 as 14 01:02.160 --> 01:09.960 the admins, we have total control over the queues that we're creating as well 15 01:09.960 --> 01:10.160 as 16 01:10.160 --> 01:15.560 which traffic goes into which queues. So here's how this ends up working. Let's 17 01:15.560 --> 01:21.480 say that we want to create let's just say six different queues. So one, two, 18 01:21.480 --> 01:21.760 three, 19 01:21.760 --> 01:27.760 four, five, six. So once again we're going to look at traffic marking and we're 20 01:27.760 --> 01:36.880 going to perform classification based on the marking. And so we might place our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 20 01:27.760 --> 01:36.880 going to perform classification based on the marking. And so we might place our 21 01:36.880 --> 01:42.680 voiceover IP traffic. Let's say we have DSCP of EF and all of those packets go 22 01:42.680 --> 01:49.720 into the top queue. We might do something like AF 40 X maybe all of the assured 23 01:49.720 --> 01:54.760 forwarding that has a priority of four goes into the next queue and then AF of 24 01:54.760 --> 01:59.830 three X in here. So three three three two three one and so on and so forth. And 25 01:59.830 --> 01:59.960 so 26 01:59.960 --> 02:05.040 we could do this all the way down and then have a best effort queue. So there WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 26 01:59.960 --> 02:05.040 we could do this all the way down and then have a best effort queue. So there 27 02:05.040 --> 02:08.320 you go. There's six queues that we created that uses all of those per hot 28 02:08.320 --> 02:13.480 behaviors that we talked about. Furthermore, we can actually assign bandwidth 29 02:13.480 --> 02:17.800 reservations to each one of these queues. And so we could say that our EF 30 02:17.800 --> 02:21.820 traffic is guaranteed 10% of the bandwidth. This could be percentage based. It 31 02:21.820 --> 02:22.040 can be 32 02:22.040 --> 02:29.000 a raw bytes and bits rate basis. It just depends on the link type and what we 33 02:29.000 --> 02:32.800 want to do there. We could go on down here. We could say we're going to reserve WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 33 02:29.000 --> 02:32.800 want to do there. We could go on down here. We could say we're going to reserve 34 02:32.800 --> 02:33.600 10% 35 02:33.600 --> 02:40.960 for EF and maybe 20% for what would probably be video traffic and AF for X 36 02:40.960 --> 02:45.960 world. And then from there we can just kind of go down and say something like 37 02:45.960 --> 02:54.240 15%, 15%, 15%. So that's 45, 55, 75. So at least 25% for best effort, which is 38 02:54.240 --> 02:58.560 actually about perfect because we typically do want to leave at least 25% for 39 02:58.560 --> 03:05.200 our best effort traffic. We can also define each one of these from a packet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 39 02:58.560 --> 03:05.200 our best effort traffic. We can also define each one of these from a packet 40 03:05.200 --> 03:09.200 length perspective or a queue length perspective. So how many packets can go 41 03:09.200 --> 03:13.680 in each queue? We do have that as an option if we really want to fine tune this 42 03:13.880 --> 03:19.500 creation of these queues. And so packets in each queue are going to be lined up 43 03:19.500 --> 03:19.520 , 44 03:19.520 --> 03:24.560 just like what we've drawn here. And so within each queue, within each 45 03:24.560 --> 03:31.160 prioritization level, we're going to run first in first out. So this packet, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 45 03:24.560 --> 03:31.160 prioritization level, we're going to run first in first out. So this packet, 46 03:31.160 --> 03:31.280 for 47 03:31.280 --> 03:36.480 example, is going to go before this packet within the queue. And then lastly, 48 03:36.480 --> 03:41.000 with best effort, interestingly, as we fill packets into this queue, this 49 03:41.000 --> 03:46.960 actually gets serviced based on weighted fair queuing, if we so desire. So we 50 03:46.960 --> 03:52.360 can do FIFO, or we can do weighted fair queuing. So if we wanted to, we could 51 03:52.360 --> 03:59.320 carve this up into the thousands of flow based queues. And that way that one 52 03:59.320 --> 04:04.760 individual flow can't dominate the queue. So something to keep in mind in some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 03:59.320 --> 04:04.760 individual flow can't dominate the queue. So something to keep in mind in some 53 04:04.760 --> 04:08.760 environments that might make a lot of sense. But all of the other queues, they 54 04:08.760 --> 04:12.720 are just going to be first in and first out. Now from here, we're going to have 55 04:12.720 --> 04:18.800 that scheduler. And the scheduler's job is to make sure that we are abiding by 56 04:18.800 --> 04:22.680 these different percentage amounts. And so we're going to get some amount of 57 04:22.680 --> 04:27.120 traffic from the top queue. And then we're going to get, you know, probably 58 04:27.120 --> 04:27.480 twice 59 04:27.480 --> 04:32.040 as much in theory from the next queue and so on and so forth. So we'll see how WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 59 04:27.480 --> 04:32.040 as much in theory from the next queue and so on and so forth. So we'll see how 60 04:32.040 --> 04:36.640 much traffic ends up getting sent out out of each one. But we do see that we 61 04:36.640 --> 04:36.760 are 62 04:36.760 --> 04:41.840 fairly getting to all of the traffic. And it doesn't matter what order they 63 04:41.840 --> 04:45.660 arrive. For example, all three of these packets could have arrived before 64 04:45.660 --> 04:46.000 either 65 04:46.000 --> 04:50.600 of these EF packets, assuming they voice over IP packets. And yet we're going 66 04:50.600 --> 04:50.680 to 67 04:50.680 --> 04:55.040 make sure that we're servicing those packets in order to achieve the bandwidth 68 04:55.040 --> 05:01.440 goals. One of the beautiful parts about class based weighted fair queuing is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 68 04:55.040 --> 05:01.440 goals. One of the beautiful parts about class based weighted fair queuing is 69 05:01.440 --> 05:02.080 also 70 05:02.160 --> 05:08.960 that bandwidth reservations are flexible. Meaning that unused bandwidth 71 05:08.960 --> 05:10.440 actually 72 05:10.440 --> 05:17.240 gets shared. Not every network platform is able to do this. Not every router 73 05:17.240 --> 05:17.400 and 74 05:17.400 --> 05:20.640 switch out there. And so this is actually something that shouldn't be 75 05:20.640 --> 05:21.520 overlooked. 76 05:21.520 --> 05:26.000 If for example, there's just no voice over IP traffic, we're getting tons of 77 05:26.000 --> 05:32.120 traffic down here. Well, it can use that 10% of bandwidth and send more traffic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 05:26.000 --> 05:32.120 traffic down here. Well, it can use that 10% of bandwidth and send more traffic 78 05:32.120 --> 05:36.480 based on the current network loads. And so that is again, is something that we 79 05:36.480 --> 05:41.120 shouldn't overlook when it comes to Cisco devices. Now a problem, if we want to 80 05:41.120 --> 05:44.400 call it that at this point, because this is actually a pretty good solution. 81 05:44.400 --> 05:44.560 But 82 05:44.560 --> 05:48.440 there is still a problem we need to call it what it is. And that is that we 83 05:48.440 --> 05:48.880 lack 84 05:48.880 --> 05:53.240 any sense of prioritization. I mentioned that these packets up here would get 85 05:53.240 --> 05:58.040 serviced fairly, but we actually are okay with a little bit of unfairness. If 86 05:58.040 --> 06:01.880 we've got all of these packets that are waiting, and then a voice over IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 86 05:58.040 --> 06:01.880 we've got all of these packets that are waiting, and then a voice over IP 87 06:01.880 --> 06:02.320 packet 88 06:02.320 --> 06:06.680 comes through, we're actually okay with just immediately sending that as long 89 06:06.680 --> 06:06.800 as 90 06:06.800 --> 06:12.200 it abides by the percentage that we set there, we don't want to go past 10% 91 06:12.200 --> 06:13.160 because 92 06:13.160 --> 06:23.480 yes, we want prioritization. That's important, but we want no starvation. So 93 06:23.480 --> 06:27.520 it feels like it's a lot to ask for, but we have this bandwidth reservation. 94 06:27.520 --> 06:27.680 And 95 06:27.680 --> 06:35.360 so what we can do is we can create what's known as a low latency queue or LLQ. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 95 06:27.680 --> 06:35.360 so what we can do is we can create what's known as a low latency queue or LLQ. 96 06:35.360 --> 06:35.560 So 97 06:35.560 --> 06:40.520 the low latency queue, which can also be referred to as low latency queuing. So 98 06:40.520 --> 06:45.520 it's kind of an upgraded form of class based weighted fair queuing. Now we can 99 06:45.520 --> 06:53.760 call it low latency queuing, basically creates a strict priority queue. And yes 100 06:53.760 --> 06:53.760 , 101 06:53.760 --> 06:59.040 I'm putting this into quotes on purpose, because it's not fully strict. It also 102 06:59.040 --> 07:08.920 turns the bandwidth reservation into a limit. So this creates two situations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 102 06:59.040 --> 07:08.920 turns the bandwidth reservation into a limit. So this creates two situations. 103 07:08.920 --> 07:14.520 First of all, if a packet does arrive, it will get immediately sent out. That 104 07:14.520 --> 07:14.800 is 105 07:14.800 --> 07:21.520 the point of having a low latency queue. And yes, we are typically going to 106 07:21.520 --> 07:27.600 reserve this for voice over IP traffic, which is marked with the SCP E F. So 107 07:27.600 --> 07:27.840 this 108 07:27.840 --> 07:34.280 top queue now becomes our LLQ packets show up, they get immediately sent out WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 108 07:27.840 --> 07:34.280 top queue now becomes our LLQ packets show up, they get immediately sent out 109 07:34.280 --> 07:34.520 the 110 07:34.520 --> 07:39.280 interface, even if all of the other packets are waiting. So is that fair? No, 111 07:39.280 --> 07:44.640 but we're actually okay with that. We like the fact that it's not fair, because 112 07:44.640 --> 07:49.260 we're treating the voice over IP traffic like it really needs to be treated. 113 07:49.260 --> 07:49.600 But 114 07:49.640 --> 07:56.370 again, this bandwidth now becomes a limit, meaning that if voice track packets 115 07:56.370 --> 07:56.600 pile 116 07:56.600 --> 08:02.640 up so much that we have 10% of the band network bandwidth that we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 07:56.600 --> 08:02.640 up so much that we have 10% of the band network bandwidth that we're going to 117 08:02.640 --> 08:02.800 be 118 08:02.800 --> 08:07.840 consuming, well, we can't just keep servicing packets at that point without 119 08:07.840 --> 08:12.680 starving all of these other queues. So we are going to continue to perform 120 08:12.680 --> 08:17.080 scheduling operations that will service these other queues and make sure that 121 08:17.080 --> 08:21.760 we're not starving them. So it's really best of all world's approach. And it's 122 08:21.760 --> 08:26.320 really it's something that Cisco came up with a long time ago. And it is the 123 08:26.320 --> 08:31.080 type of queuing that we deploy into our modern networks and Cisco platforms. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 123 08:26.320 --> 08:31.080 type of queuing that we deploy into our modern networks and Cisco platforms. 124 08:31.080 --> 08:35.880 Now the way that we deploy these two queuing mechanisms is with a configuration 125 08:35.880 --> 08:42.240 methodology that is known as modular QOS config or MQC. We're going to take a 126 08:42.240 --> 08:46.400 look at MQC coming up. But this is where we're going to find that we've got 127 08:46.480 --> 08:50.840 commands such as class maps and policy maps and service policies, some 128 08:50.840 --> 08:55.640 configuration commands that a lot of us might be familiar with from maybe doing 129 08:55.640 --> 09:00.140 QOS in the past. But either way, we're going to see how this can be leveraged WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 129 08:55.640 --> 09:00.140 QOS in the past. But either way, we're going to see how this can be leveraged 130 09:00.140 --> 09:00.280 to 131 09:00.280 --> 09:04.240 create the number of queues that we want map the policy that we want, such as 132 09:04.240 --> 09:07.760 bandwidth and queue length. And then also make sure that we configure that low 133 09:07.760 --> 09:14.560 latency queue for the sake of adding priority functionality to our QOS 134 09:14.560 --> 09:16.540 deployment for the sake of voice over IP.