WEBVTT 1 00:00.000 --> 00:06.620 So here's the goal. We have an upstream ISP router or some device that's 2 00:06.620 --> 00:07.280 performing 3 00:07.280 --> 00:12.250 policing. And we know that if policing is going to decide which packets to drop 4 00:12.250 --> 00:12.920 , it's 5 00:12.920 --> 00:17.950 not going to care about the tags. It's just going to drop traffic indiscrim 6 00:17.950 --> 00:18.520 inately, as 7 00:18.520 --> 00:25.480 we've said. So what we want to do is we want to be able to configure traffic 8 00:25.480 --> 00:26.320 shaping on 9 00:26.320 --> 00:32.680 our router, which essentially means that we are going to drop the packets. But WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:26.320 --> 00:32.680 our router, which essentially means that we are going to drop the packets. But 10 00:32.680 --> 00:32.960 what this 11 00:32.960 --> 00:38.030 means here, functionally, is that remember, we said we have a 75 megabit 12 00:38.030 --> 00:39.040 connection, 13 00:39.040 --> 00:46.280 but it's on a 100 meg line. So we are at risk of sending at 100 megabits per 14 00:46.280 --> 00:46.480 second. And 15 00:46.480 --> 00:50.500 that could result in dropped traffic. So what we're going to do instead is make 16 00:50.500 --> 00:50.960 sure we 17 00:50.960 --> 00:56.280 never transmit at that rate. Instead, we're going to transmit at 75 megabits 18 00:56.280 --> 00:57.280 per second. 19 00:57.280 --> 01:02.280 But what about the situation where we have all of this traffic coming in, and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:57.280 --> 01:02.280 But what about the situation where we have all of this traffic coming in, and 20 01:02.280 --> 01:02.760 we've got 21 01:02.760 --> 01:07.390 a bunch more traffic that we have to send than what 75 megabits per second 22 01:07.390 --> 01:09.080 allows? Well, 23 01:09.080 --> 01:14.060 that's what shaping is meant to do for us. Shaping is also going to run the 24 01:14.060 --> 01:14.960 same token 25 01:14.960 --> 01:24.270 bucket policy. And the general idea here is that we want to match the policy 26 01:24.270 --> 01:25.440 that's on 27 01:25.440 --> 01:31.200 the police. If we match the policy, it's on the police, or then we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 27 01:25.440 --> 01:31.200 the police. If we match the policy, it's on the police, or then we're going to 28 01:31.200 --> 01:33.440 only send 29 01:33.440 --> 01:38.460 when there's a token. And if there are no tokens in the bucket, that means that 30 01:38.460 --> 01:38.880 we are 31 01:38.880 --> 01:43.430 going to have to drop a packet. Well, keep in mind, if we have the exact same 32 01:43.430 --> 01:44.880 policy configured, 33 01:44.880 --> 01:50.510 that meant that the police also has zero tokens in the bucket, and it would 34 01:50.510 --> 01:51.520 have dropped the 35 01:51.520 --> 01:56.790 packet. But we're not going to let it. We're going to drop the packet ourselves 36 01:56.790 --> 01:57.680 before the 37 01:57.680 --> 02:03.030 police ever gets a chance to do so. Now, if we wait until the last possible WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 37 01:57.680 --> 02:03.030 police ever gets a chance to do so. Now, if we wait until the last possible 38 02:03.030 --> 02:05.920 token is gone, 39 02:05.920 --> 02:10.020 this might be an AF 41 packet, which we've used as an example to represent a 40 02:10.020 --> 02:11.600 high priority packet. 41 02:11.600 --> 02:15.780 And so we'd have to drop the high priority and that's no good. So instead, what 42 02:15.780 --> 02:16.480 we're going to do 43 02:16.480 --> 02:22.120 is we're going to rely on our weighted random early detect, because this is 44 02:22.120 --> 02:23.520 running on the queues 45 02:23.520 --> 02:30.450 themselves. We know that we can just hold packets in the queue. And so WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 45 02:23.520 --> 02:30.450 themselves. We know that we can just hold packets in the queue. And so 46 02:30.450 --> 02:32.320 ultimately, what we're saying 47 02:32.320 --> 02:35.910 is we're not going to just drop a packet because it's time to send a packet and 48 02:35.910 --> 02:37.440 there's no tokens. 49 02:37.440 --> 02:42.140 Instead, what we're going to do is we're going to hold our position. We're just 50 02:42.140 --> 02:42.880 going to 51 02:42.880 --> 02:50.140 not transmit a packet if we know that there's no token on the other side. Now, 52 02:50.140 --> 02:51.200 what happens 53 02:51.200 --> 02:54.280 eventually if we're just holding and not transmitting packets, well, we know 54 02:54.280 --> 02:55.520 what's going to happen 55 02:55.520 --> 02:59.720 is our queues are going to fill up over time. And even though tokens are 56 02:59.720 --> 03:01.360 getting inserted in at a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 56 02:59.720 --> 03:01.360 getting inserted in at a 57 03:01.360 --> 03:08.780 particular rate, we are going to find that the sending the occasional packet, 58 03:08.780 --> 03:09.600 if we're overloaded, 59 03:09.600 --> 03:13.560 is not going to ease up on these queues. This is why red is so important, 60 03:13.560 --> 03:14.800 because each one of these 61 03:14.800 --> 03:19.870 queues is going to be performing some amount of that random percentage for 62 03:19.870 --> 03:21.120 dropping frames, 63 03:21.120 --> 03:25.700 or dropping packets, which means that as packets are coming into these queues, 64 03:25.700 --> 03:26.480 we might see that, 65 03:26.480 --> 03:30.800 hey, I've got a 43 coming in, I'd better drop that. And a 41 is coming in, oh, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 65 03:26.480 --> 03:30.800 hey, I've got a 43 coming in, I'd better drop that. And a 41 is coming in, oh, 66 03:30.800 --> 03:31.840 we're going to place 67 03:31.840 --> 03:36.330 that into the queue and try to manage our queues as much as possible. So now 68 03:36.330 --> 03:38.160 red is even more important 69 03:38.160 --> 03:43.430 with a shaping policy, because as we hold and don't send to the police, or now 70 03:43.430 --> 03:44.400 we need to still 71 03:44.400 --> 03:48.140 make sure that on the back end that we're dropping the appropriate packets. So 72 03:48.140 --> 03:49.920 now because of this, 73 03:50.720 --> 03:56.120 we're going to find that there is never in theory a reason to drop a packet. 74 03:56.120 --> 03:57.680 Instead, all drops are 75 03:57.680 --> 04:03.600 managed by us and by weighted random early detect. Now an important part of all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 75 03:57.680 --> 04:03.600 managed by us and by weighted random early detect. Now an important part of all 76 04:03.600 --> 04:04.800 of this is to think 77 04:04.800 --> 04:10.740 about the direction of these different policies. So notice, if I'm going to be 78 04:10.740 --> 04:11.280 shaping 79 04:11.280 --> 04:18.960 my traffic, this is an outgoing, otherwise known as an egress type of policy. I 80 04:18.960 --> 04:19.680 'm not going to 81 04:19.680 --> 04:24.220 shape as I bring packets into my router, it doesn't make any sense, I can't 82 04:24.220 --> 04:26.000 actually do that. But I 83 04:26.000 --> 04:30.690 can shape when I'm sending upstream, especially if I know that there's a police WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 83 04:26.000 --> 04:30.690 can shape when I'm sending upstream, especially if I know that there's a police 84 04:30.690 --> 04:32.000 or upstream. This 85 04:32.000 --> 04:38.770 is typically when we want to deploy a shaper. Meanwhile, conversely, our 86 04:38.770 --> 04:42.080 policing is typically 87 04:42.080 --> 04:46.590 an ingress policy. Now Cisco does allow us to configure this on an outgoing 88 04:46.590 --> 04:47.440 interface. 89 04:48.160 --> 04:53.050 But usually it's better to configure shaping on an outgoing interface. But keep 90 04:53.050 --> 04:53.840 in mind that just 91 04:53.840 --> 04:59.070 from a practical real world perspective, that policing maps to ingress or 92 04:59.070 --> 05:00.640 incoming interfaces, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 92 04:59.070 --> 05:00.640 incoming interfaces, 93 05:00.640 --> 05:04.550 because I'm going to drop traffic that you're sending me if it's too much. 94 05:04.550 --> 05:06.240 Meanwhile, I'm trying 95 05:06.240 --> 05:12.810 to match your policy and meet you with traffic shaping. And so ultimately what 96 05:12.810 --> 05:13.920 we have, if we can 97 05:13.920 --> 05:18.480 try to visualize this a little bit, is I'm going to allow this much traffic, 98 05:18.480 --> 05:20.240 whatever this amount 99 05:20.240 --> 05:25.220 is, this is what's allowed. And so with my shaping policy, I might have this 100 05:25.220 --> 05:26.400 much traffic. 101 05:26.400 --> 05:32.950 So this is my packets that I have to send. So what I'm going to do is I'm going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 101 05:26.400 --> 05:32.950 So this is my packets that I have to send. So what I'm going to do is I'm going 102 05:32.950 --> 05:34.880 to shape it down 103 05:34.880 --> 05:40.400 to meet your restrictions. And yes, if this means that I have to drop my own 104 05:40.400 --> 05:41.840 traffic in the meantime, 105 05:41.840 --> 05:47.830 then so be it. But for the most part, my initial desire is just to hold my 106 05:47.830 --> 05:48.880 transmits, 107 05:48.880 --> 05:53.520 so that I'm only transmitting such that when you receive a packet, I know that 108 05:53.520 --> 05:54.160 you're not going 109 05:54.160 --> 06:01.830 to drop it. So as we see shaping compliments, policing in a very meaningful way WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 05:54.160 --> 06:01.830 to drop it. So as we see shaping compliments, policing in a very meaningful way 110 06:01.830 --> 06:02.480 , and we should 111 06:02.480 --> 06:06.990 expect to be deploying shaping on any interface where we expect traffic to be 112 06:06.990 --> 06:08.080 dropped upstream 113 06:08.080 --> 06:10.480 if we exceed or violate a policy.