WEBVTT 1 00:00.000 --> 00:06.000 One of the best ways to think of network bandwidth is to think of it like it's 2 00:06.000 --> 00:08.120 a conveyor belt. 3 00:08.120 --> 00:13.070 So a conveyor belt, anything about maybe a factory type of situation, it's 4 00:13.070 --> 00:13.520 moving at 5 00:13.520 --> 00:16.640 a constant speed. 6 00:16.640 --> 00:21.420 And so we can imagine a situation where you or I, somebody is sitting here, and 7 00:21.420 --> 00:22.000 they're 8 00:22.000 --> 00:27.560 responsible for taking boxes that are maybe stacked up here and placing the 9 00:27.560 --> 00:28.320 boxes onto 10 00:28.320 --> 00:29.880 the conveyor belt. 11 00:29.880 --> 00:34.410 Now we can only put one box onto the conveyor belt at a time at the point of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:29.880 --> 00:34.410 Now we can only put one box onto the conveyor belt at a time at the point of 12 00:34.410 --> 00:35.200 entry. 13 00:35.200 --> 00:40.920 So naturally as this box moves down, we can put more boxes behind it. 14 00:40.920 --> 00:44.160 I don't know, I think about maybe being at the grocery store, sometimes this 15 00:44.160 --> 00:44.560 happens 16 00:44.560 --> 00:48.230 where I've got a cart full of goods and somebody's getting checked out in front 17 00:48.230 --> 00:48.440 of 18 00:48.440 --> 00:52.230 me and I put one of these barriers down on the conveyor belt and I can stack my 19 00:52.230 --> 00:52.640 stuff 20 00:52.640 --> 00:53.920 up here. 21 00:53.920 --> 00:57.440 But until the conveyor belt moves enough, I can't put all of my stuff there. 22 00:57.440 --> 01:02.760 So I end up having to sit there and wait to put all of my groceries onto the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 22 00:57.440 --> 01:02.760 So I end up having to sit there and wait to put all of my groceries onto the 23 01:02.760 --> 01:03.560 checkout 24 01:03.560 --> 01:06.160 conveyor belt at the grocery store. 25 01:06.160 --> 01:11.840 So it's that kind of same situation where we've got a bunch of boxes stacked up 26 01:11.840 --> 01:12.200 here 27 01:12.200 --> 01:14.880 and we need to get all of them across. 28 01:14.880 --> 01:20.250 Well, it doesn't matter technically speaking how fast or slow this conveyor 29 01:20.250 --> 01:21.000 belt is, at 30 01:21.000 --> 01:25.320 least as far as how many of these boxes I can put on at a time. 31 01:25.320 --> 01:31.190 What does matter is the faster that it is, the faster I'm going to be able to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 01:25.320 --> 01:31.190 What does matter is the faster that it is, the faster I'm going to be able to 32 01:31.190 --> 01:31.880 deplete 33 01:31.880 --> 01:33.480 these boxes. 34 01:33.480 --> 01:38.550 Now the other part of this analogy that's important is that we have some kind 35 01:38.550 --> 01:39.320 of supply 36 01:39.320 --> 01:42.680 that's going to feed us with more boxes. 37 01:42.680 --> 01:49.170 So we have a speed at which the boxes are showing up and we have a speed at 38 01:49.170 --> 01:50.200 which the 39 01:50.200 --> 01:53.880 boxes are getting put onto the conveyor belt. 40 01:53.880 --> 01:59.240 If as we might imagine, if the speed of the supply is actually faster than the 41 01:59.240 --> 01:59.880 speed of 42 01:59.880 --> 02:03.240 the conveyor belt, then we're going to have a major problem here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:59.880 --> 02:03.240 the conveyor belt, then we're going to have a major problem here. 43 02:03.240 --> 02:06.650 Eventually, we're going to have so many boxes that they're piling up and 44 02:06.650 --> 02:07.920 spilling out and 45 02:07.920 --> 02:11.950 potentially we even have to reject some of those boxes from coming in because 46 02:11.950 --> 02:12.440 we have 47 02:12.440 --> 02:14.360 no place to store them. 48 02:14.360 --> 02:20.920 So this analogy is exactly what's happening from the perspective of a network 49 02:20.920 --> 02:21.920 device. 50 02:21.920 --> 02:27.680 For example, we have an ingress interface here that's receiving packets. 51 02:27.680 --> 02:32.380 So we have packets that are coming into the network device. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 51 02:27.680 --> 02:32.380 So we have packets that are coming into the network device. 52 02:32.380 --> 02:39.140 We have a buffer, some amount of space where we can store packets and then we 53 02:39.140 --> 02:40.000 have the 54 02:40.000 --> 02:46.250 egress interface and the egress interface is operating at a particular 55 02:46.250 --> 02:47.600 bandwidth. 56 02:47.600 --> 02:52.220 Now, unfortunately, we might actually have multiple ingress interfaces so we 57 02:52.220 --> 02:52.840 could have 58 02:52.840 --> 02:57.080 packets coming in from all different directions here. 59 02:57.080 --> 03:01.420 And so we don't even have to have very high bandwidth ingress interfaces in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 59 02:57.080 --> 03:01.420 And so we don't even have to have very high bandwidth ingress interfaces in 60 03:01.420 --> 03:03.000 order to overwhelm 61 03:03.000 --> 03:04.760 maybe our one egress interface. 62 03:04.760 --> 03:09.050 If we have a router with lots of interfaces and most of the packets that are 63 03:09.050 --> 03:09.760 coming in 64 03:09.760 --> 03:12.980 are destined out a single interface, well, now we see why we could have a 65 03:12.980 --> 03:13.600 problem and 66 03:13.600 --> 03:17.480 why we could start having packets stack up. 67 03:17.480 --> 03:20.480 So now we are presented with another problem. 68 03:20.480 --> 03:27.080 What happens in our analogy here if a very important packet shows up? 69 03:27.080 --> 03:30.680 So now this is a priority packet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 69 03:27.080 --> 03:30.680 So now this is a priority packet. 70 03:30.680 --> 03:36.440 If we were shipping our packages, maybe we're working for the post office or 71 03:36.440 --> 03:37.600 the mail service 72 03:37.600 --> 03:42.000 or something along those lines where we are trying to ship as many of these 73 03:42.000 --> 03:43.720 boxes as possible, 74 03:43.720 --> 03:48.100 well, we know that we can go to the post office and we can say, hey, I would 75 03:48.100 --> 03:48.800 like to send 76 03:48.800 --> 03:53.400 this as a priority shipment and in theory, it will arrive faster. 77 03:53.400 --> 03:55.040 So same concept here. 78 03:55.040 --> 03:59.680 Priority box does show up and now I need to put the priority box on to the 79 03:59.680 --> 04:00.800 conveyor belt WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 03:59.680 --> 04:00.800 conveyor belt 80 04:00.800 --> 04:02.520 as fast as I can. 81 04:02.520 --> 04:04.640 Well, here's the problem. 82 04:04.640 --> 04:09.320 I'm looking at this stack of boxes and I'm seeing nine other boxes that were 83 04:09.320 --> 04:10.040 delivered 84 04:10.040 --> 04:11.640 before the priority. 85 04:11.640 --> 04:16.120 So this is technically number 10 in the list. 86 04:16.120 --> 04:22.040 So the question is, how am I servicing these boxes? 87 04:22.040 --> 04:25.860 Am I taking the first box that showed up here and then I'll take the second box 88 04:25.860 --> 04:26.240 and then 89 04:26.240 --> 04:29.720 I'll take the third box and I'll just keep going in order? 90 04:29.720 --> 04:33.260 Because if that's the case, it's going to take me a long time to get to that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 04:29.720 --> 04:33.260 Because if that's the case, it's going to take me a long time to get to that 91 04:33.260 --> 04:33.800 box that's 92 04:33.800 --> 04:35.600 all the way in the back. 93 04:35.600 --> 04:40.850 Now if I'm just getting fed one box at a time, then I don't have a choice and 94 04:40.850 --> 04:41.120 maybe 95 04:41.120 --> 04:44.940 in our analogy here, maybe that priority package is so far in the back that I 96 04:44.940 --> 04:45.360 don't 97 04:45.360 --> 04:47.840 even know that it's there. 98 04:47.840 --> 04:54.140 So we need to come up with a way to better service how we can grab those 99 04:54.140 --> 04:56.080 priority packages 100 04:56.080 --> 05:01.910 and get them out our conveyor belt or our egress interface from a networking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 100 04:56.080 --> 05:01.910 and get them out our conveyor belt or our egress interface from a networking 101 05:01.910 --> 05:03.480 perspective. 102 05:03.480 --> 05:09.440 And the way we're going to accomplish this is with the concept of queues. 103 05:09.440 --> 05:14.830 So queues, that's just another way of saying we get in line at the bank or at 104 05:14.830 --> 05:16.120 the restaurant 105 05:16.120 --> 05:18.800 or anything like that, we're going to queue up. 106 05:18.800 --> 05:21.040 Our British friends are all very happy. 107 05:21.040 --> 05:25.130 It's a little bit more of a British word than an American word when it comes to 108 05:25.130 --> 05:25.880 English. 109 05:25.880 --> 05:31.590 But ultimately, what we're saying is we're going to form multiple queues or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 05:25.880 --> 05:31.590 But ultimately, what we're saying is we're going to form multiple queues or 110 05:31.590 --> 05:32.160 lines that 111 05:32.160 --> 05:36.480 allow us to see that there are priority packages. 112 05:36.480 --> 05:39.560 So imagine this now. 113 05:39.560 --> 05:41.880 Now I am going to draw this out again. 114 05:41.880 --> 05:42.880 Same situation. 115 05:42.880 --> 05:44.080 We have our conveyor belt. 116 05:44.080 --> 05:45.760 We have our person. 117 05:45.760 --> 05:52.190 But now as the packages start stacking up over here, we're going to call this 118 05:52.190 --> 05:53.120 our normal 119 05:53.120 --> 05:57.040 queue. 120 05:57.040 --> 06:04.080 And up here, we're going to have a priority queue. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 120 05:57.040 --> 06:04.080 And up here, we're going to have a priority queue. 121 06:04.080 --> 06:06.960 So for the most part, we're just going to get normal packages. 122 06:06.960 --> 06:11.080 I'm going to be taking these packages and putting them on the conveyor belt. 123 06:11.080 --> 06:15.370 But then all of a sudden, after we have, once again, let's say we've got nine 124 06:15.370 --> 06:15.840 packages 125 06:15.840 --> 06:20.000 lined up, we'll now a priority package arrives. 126 06:20.000 --> 06:21.000 Where are we going to put it? 127 06:21.000 --> 06:26.520 Well, we're going to move it right up here to the front of the priority queue. 128 06:26.520 --> 06:30.860 So now this box over here on the conveyor belt sends, and this person turns WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 128 06:26.520 --> 06:30.860 So now this box over here on the conveyor belt sends, and this person turns 129 06:30.860 --> 06:31.480 around and 130 06:31.480 --> 06:33.280 they see they have two choices. 131 06:33.280 --> 06:37.430 They can take one of the boxes from the normal queue, or they can take the box 132 06:37.430 --> 06:38.480 from the priority 133 06:38.480 --> 06:39.480 queue. 134 06:39.480 --> 06:43.200 Naturally, the whole reason we have the priority queue is so that I can grab 135 06:43.200 --> 06:44.120 the priority queue 136 06:44.120 --> 06:47.440 packet and put it onto the conveyor belt. 137 06:47.440 --> 06:53.150 This allows us to be able to service a different level of priority, namely the 138 06:53.150 --> 06:54.400 priority marked 139 06:54.400 --> 06:56.280 packages that show up. 140 06:56.280 --> 07:00.840 And as we can imagine, this has a direct translation to our networking devices WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 140 06:56.280 --> 07:00.840 And as we can imagine, this has a direct translation to our networking devices 141 07:00.840 --> 07:01.520 up here. 142 07:01.520 --> 07:05.480 So now we have a bunch of packets showing up, but some of those are voice over 143 07:05.480 --> 07:06.280 IP packets. 144 07:06.280 --> 07:08.280 They're priority packets. 145 07:08.280 --> 07:13.090 And so rather than lining them all up to be sent out the egress interface in 146 07:13.090 --> 07:13.800 the, the 147 07:13.800 --> 07:18.350 order in which they arrived, well, now we can actually look at two different 148 07:18.350 --> 07:19.440 options. 149 07:19.440 --> 07:23.810 Here, we can line them up in two different queues, and I can service the 150 07:23.810 --> 07:25.120 priority packages 151 07:25.120 --> 07:27.120 when they show up. 152 07:27.120 --> 07:30.600 Furthermore, we could say, you know, let's not stop there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 07:27.120 --> 07:30.600 Furthermore, we could say, you know, let's not stop there. 153 07:30.600 --> 07:34.000 We could have this normal queue in the priority queue, but maybe we could have 154 07:34.000 --> 07:34.640 an upgraded 155 07:34.640 --> 07:40.600 queue, sort of that economy plus style where we don't want to pay for a 156 07:40.600 --> 07:42.040 priority ship. 157 07:42.040 --> 07:45.040 And maybe this costs a lot of money. 158 07:45.040 --> 07:49.450 And I can spend a lot less money on the normal queue, but maybe I've got a an 159 07:49.450 --> 07:51.240 upgraded set. 160 07:51.240 --> 07:55.410 So I could actually spend maybe not as much as priority, but a little bit more 161 07:55.410 --> 07:55.820 than a 162 07:55.820 --> 07:59.080 normal queue to get placed here. 163 07:59.080 --> 08:02.320 And so now I actually have the normal queue. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 163 07:59.080 --> 08:02.320 And so now I actually have the normal queue. 164 08:02.320 --> 08:05.820 I have the priority queue, and then I have packages showing up here that are 165 08:05.820 --> 08:06.520 the upgraded 166 08:06.520 --> 08:07.520 queue. 167 08:07.520 --> 08:11.690 And so these could actually get serviced before the normal ones, but after the 168 08:11.690 --> 08:12.760 priority queue, 169 08:12.760 --> 08:15.120 it has been fully serviced. 170 08:15.120 --> 08:17.920 So we've got lots of options here. 171 08:17.920 --> 08:21.600 We can have many different queues, for example, and that allows us to have many 172 08:21.600 --> 08:22.640 different priority 173 08:22.640 --> 08:23.920 levels. 174 08:23.920 --> 08:29.120 And so I can make a difference, for example, between priority traffic and 175 08:29.120 --> 08:30.440 upgraded traffic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 175 08:29.120 --> 08:30.440 upgraded traffic 176 08:30.440 --> 08:34.440 while still prioritizing both of those relative to the normal queue. 177 08:34.440 --> 08:37.990 Now an important thing that I like to point out at this point is it's at least 178 08:37.990 --> 08:38.560 ask this 179 08:38.560 --> 08:43.300 question, which is, are we sending more boxes like this? 180 08:43.300 --> 08:48.960 If I had just the single normal queue, I would get, let's say, 100 packages out 181 08:48.960 --> 08:50.120 per hour, 182 08:50.120 --> 08:51.220 something like that. 183 08:51.220 --> 08:56.100 So if I put all of these boxes into the queues, do I send more than 100 boxes 184 08:56.100 --> 08:57.080 in that hour? 185 08:57.080 --> 09:00.940 And the answer is no, I'm not sending any more boxes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 185 08:57.080 --> 09:00.940 And the answer is no, I'm not sending any more boxes. 186 09:00.940 --> 09:04.670 This is what we talked about in the last video where QOS is not about sending 187 09:04.670 --> 09:05.580 more traffic 188 09:05.580 --> 09:08.080 and making sure we don't drop any traffic. 189 09:08.080 --> 09:12.980 QOS is about making sure that we have total control over what traffic is being 190 09:12.980 --> 09:13.620 sent and 191 09:13.620 --> 09:15.620 what traffic is being dropped. 192 09:15.620 --> 09:18.340 And that is what quality of service is all about. 193 09:18.340 --> 09:22.700 So again, we're not sending any more boxes than we were before, but we do have 194 09:22.700 --> 09:24.100 full control 195 09:24.100 --> 09:26.560 over which boxes are being sent. 196 09:26.560 --> 09:28.740 And that is the point. 197 09:28.740 --> 09:33.830 So let's drop the analogies and start talking about this from a true network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 197 09:28.740 --> 09:33.830 So let's drop the analogies and start talking about this from a true network 198 09:33.830 --> 09:35.080 perspective. 199 09:35.080 --> 09:37.980 Once again, we're going to have a network device. 200 09:37.980 --> 09:42.980 And this network device is going to have maybe a lot of ingress interfaces. 201 09:42.980 --> 09:47.670 The reality is that interfaces on a network device have traffic coming in and 202 09:47.670 --> 09:48.340 going out 203 09:48.340 --> 09:50.660 every single one of these. 204 09:50.660 --> 09:54.490 But for the sake of just drawing this out, let's say we've got these three 205 09:54.490 --> 09:55.220 interfaces 206 09:55.220 --> 10:00.850 and we're receiving a bunch of traffic and it is going to all be destined for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 206 09:55.220 --> 10:00.850 and we're receiving a bunch of traffic and it is going to all be destined for 207 10:00.850 --> 10:01.780 this egress 208 10:01.780 --> 10:03.900 link over here. 209 10:03.900 --> 10:09.120 Well, the egress link is going to have, let's just draw it like this, where we 210 10:09.120 --> 10:09.780 've got this 211 10:09.780 --> 10:14.140 space in here that is the buffer. 212 10:14.140 --> 10:18.180 This buffer is intended to store packets. 213 10:18.180 --> 10:24.050 We are typically receiving more packets, not packages, it's over here, packages 214 10:24.050 --> 10:24.580 , but 215 10:24.580 --> 10:28.220 we're storing more packets because we're typically getting more packets than we 216 10:28.220 --> 10:28.820 can actually 217 10:28.820 --> 10:30.860 send at once. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 217 10:28.820 --> 10:30.860 send at once. 218 10:30.860 --> 10:34.740 And that makes sense when we have a potential for so many different ingress 219 10:34.740 --> 10:35.620 interfaces. 220 10:35.620 --> 10:39.960 All of these ingress interfaces could be 100 megabits per second and this could 221 10:39.960 --> 10:40.460 also be 222 10:40.460 --> 10:44.580 100 megabits per second. 223 10:44.580 --> 10:49.840 But at maximum capacity, I might be expected to be sending 400 megabits per 224 10:49.840 --> 10:50.780 second worth 225 10:50.780 --> 10:51.780 of traffic. 226 10:51.780 --> 10:54.740 Now, fortunately, in a packet switch network, everything is bursty. 227 10:54.740 --> 10:59.460 And so sometimes this link is hot and this link isn't sending much or receiving 228 10:59.460 --> 10:59.940 much, 229 10:59.940 --> 11:01.180 I suppose. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 229 10:59.940 --> 11:01.180 I suppose. 230 11:01.180 --> 11:04.420 And vice versa and now all of those kinds of things. 231 11:04.420 --> 11:09.240 And so we're hoping that it averages out to the point that we can still manage 232 11:09.240 --> 11:09.780 to send 233 11:09.780 --> 11:11.940 our traffic on 100 meg link. 234 11:11.940 --> 11:16.320 If we're spiking and dropping traffic on this regularly, then we know that 235 11:16.320 --> 11:16.580 maybe we 236 11:16.580 --> 11:20.130 want to upgrade that link because we just have too much traffic to actually be 237 11:20.130 --> 11:20.620 sending 238 11:20.620 --> 11:22.060 on it. 239 11:22.060 --> 11:26.030 But now we can understand that as these packets are coming in, they're going to 240 11:26.030 --> 11:27.860 be stored here 241 11:27.860 --> 11:29.620 inside of the buffer. 242 11:29.620 --> 11:36.740 And it's inside this buffer that we can establish our concept of queues. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 242 11:29.620 --> 11:36.740 And it's inside this buffer that we can establish our concept of queues. 243 11:36.740 --> 11:39.960 Now the number of queues that we're going to build is going to look a little 244 11:39.960 --> 11:40.540 different 245 11:40.540 --> 11:42.500 depending on the platform. 246 11:42.500 --> 11:49.820 For example, a lot of routers are built a little bit more on software. 247 11:49.820 --> 11:55.660 And so I can have a custom queue amount, a custom number of queues because the 248 11:55.660 --> 11:55.940 router 249 11:55.940 --> 12:00.100 operates more in software and I can configure all of those as much as I want. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 249 11:55.940 --> 12:00.100 operates more in software and I can configure all of those as much as I want. 250 12:00.100 --> 12:05.110 Whereas switches, they operate more in the hardware realm and they typically 251 12:05.110 --> 12:05.900 have a set 252 12:05.900 --> 12:10.340 number of queues, usually four or eight queues depending on the platform. 253 12:10.340 --> 12:14.490 Whereas routers, maybe I can configure up to 256 different queues because it's 254 12:14.490 --> 12:14.880 simply 255 12:14.880 --> 12:16.500 carving more out in software. 256 12:16.500 --> 12:21.300 It's very software focused as far as how it handles forwarding of traffic. 257 12:21.300 --> 12:24.780 It's a big difference between routers and switches. 258 12:24.780 --> 12:31.180 So let's say I carve out four queues here, one, two, three and four. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 258 12:24.780 --> 12:31.180 So let's say I carve out four queues here, one, two, three and four. 259 12:31.180 --> 12:36.600 And what we're going to do now is we're going to perform our classification in 260 12:36.600 --> 12:37.780 marking based 261 12:37.780 --> 12:40.660 on what we're seeing here. 262 12:40.660 --> 12:42.380 Or maybe I should say it like this. 263 12:42.380 --> 12:46.700 We're going to be bringing in marked packets. 264 12:46.700 --> 12:49.860 Now some of those are marked with an actual tag. 265 12:49.860 --> 12:52.660 Some of them just have no tag or marked with zero. 266 12:52.660 --> 12:56.960 But either way, we have marked packets and we're going to classify those into 267 12:56.960 --> 12:57.740 the different 268 12:57.740 --> 12:59.180 queues. 269 12:59.180 --> 13:05.890 So what we end up with is we might end up with packets that are in every one of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 269 12:59.180 --> 13:05.890 So what we end up with is we might end up with packets that are in every one of 270 13:05.890 --> 13:06.500 these 271 13:06.500 --> 13:11.540 queues depending on the marking. 272 13:11.540 --> 13:15.140 So maybe we've got voiceover IP that goes into this queue up here. 273 13:15.140 --> 13:18.740 We've got video that goes into this queue. 274 13:18.740 --> 13:23.670 We've got some kind of, I don't know, maybe some kind of bulk traffic 275 13:23.670 --> 13:25.180 transmission happening 276 13:25.180 --> 13:26.180 here. 277 13:26.180 --> 13:30.380 And then down here, we've just got our best effort marking. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 277 13:26.180 --> 13:30.380 And then down here, we've just got our best effort marking. 278 13:30.380 --> 13:33.140 So those are the four different queues that we have. 279 13:33.140 --> 13:41.300 So now it's up to an entity, a software entity known as the scheduler. 280 13:41.300 --> 13:47.540 The scheduler's job is to decide which one of these queues to service. 281 13:47.540 --> 13:54.490 So now that I have the ability to pick and choose, sort of like my person here 282 13:54.490 --> 13:55.420 was able 283 13:55.420 --> 14:00.210 to pick and choose which one of these queues to pick from, well now that's the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 283 13:55.420 --> 14:00.210 to pick and choose which one of these queues to pick from, well now that's the 284 14:00.210 --> 14:00.780 job of the 285 14:00.780 --> 14:01.780 scheduler. 286 14:01.780 --> 14:06.630 The scheduler can pull a voiceover IP packet and then it can pull a video 287 14:06.630 --> 14:07.580 packet and it 288 14:07.580 --> 14:11.390 can pull another voiceover IP packet and then it could do a best effort and 289 14:11.390 --> 14:12.020 then it could 290 14:12.020 --> 14:13.180 do a bulk. 291 14:13.180 --> 14:18.320 And so we see that the order of packets that are being sent, we again have 292 14:18.320 --> 14:19.420 total control 293 14:19.420 --> 14:21.140 over that. 294 14:21.140 --> 14:27.060 And so that is the policy that we have to define as the network admins. 295 14:27.060 --> 14:29.980 Because the scheduler is not artificial intelligence. 296 14:29.980 --> 14:32.460 It's not making these decisions on its own. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 296 14:29.980 --> 14:32.460 It's not making these decisions on its own. 297 14:32.460 --> 14:37.140 It's making these decisions based on the policies that we set. 298 14:37.140 --> 14:42.040 And some of those policies are going to involve bandwidth reservations and that 299 14:42.040 --> 14:43.140 prioritization 300 14:43.140 --> 14:47.020 concept that we talked about. 301 14:47.020 --> 14:50.910 So from here, we're going to dive into the details of how we can build these 302 14:50.910 --> 14:51.740 queues out, 303 14:51.740 --> 14:55.150 the different methodologies that Cisco gives us, and how we can apply these 304 14:55.150 --> 14:55.740 concepts of 305 14:55.740 --> 14:59.700 bandwidth reservation and priority to the different queuing mechanisms that we 306 14:59.700 --> 15:00.020 have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 306 14:59.700 --> 15:00.020 have 307 15:00.020 --> 15:00.540 available.