WEBVTT 1 00:00.000 --> 00:04.160 All right, let's go ahead and talk through the solution here. 2 00:04.160 --> 00:08.000 A lot of this is just making sure that we understand the basic concepts of what 3 00:08.000 --> 00:08.120 we've 4 00:08.120 --> 00:12.500 been talking about to look at a problem and recognize what exactly is the 5 00:12.500 --> 00:13.360 solution or 6 00:13.360 --> 00:17.830 potentially to look at a situation to understand what QOS mechanism is being 7 00:17.830 --> 00:18.520 used. 8 00:18.520 --> 00:23.330 So first up, our knock has noticed TCP traffic is stuck in this pattern of 9 00:23.330 --> 00:24.400 going up and down. 10 00:24.400 --> 00:26.440 So remember, number one here. 11 00:26.440 --> 00:31.860 If we see TCP traffic doing this kind of shark fin or triangular type of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:26.440 --> 00:31.860 If we see TCP traffic doing this kind of shark fin or triangular type of 12 00:31.860 --> 00:32.920 approach, this is 13 00:32.920 --> 00:36.120 known as that TCP global synchronization. 14 00:36.120 --> 00:39.960 And we say we have two different techniques that can help with this. 15 00:39.960 --> 00:45.950 They're both roughly using the same underlying process to randomly drop packets 16 00:45.950 --> 00:46.760 as they come 17 00:46.760 --> 00:47.760 in. 18 00:47.760 --> 00:53.360 But one, random early detect is not going to look at the packet tags. 19 00:53.360 --> 00:57.870 It's just going to drop whatever packets are coming in regardless of the tags 20 00:57.870 --> 00:58.400 and try to 21 00:58.400 --> 01:00.320 do so randomly. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:58.400 --> 01:00.320 do so randomly. 22 01:00.320 --> 01:05.720 And then we have weighted random early detect red with a W and that means that 23 01:05.720 --> 01:06.440 we are going 24 01:06.440 --> 01:08.360 to look at the tag. 25 01:08.360 --> 01:13.060 So remember, both of these techniques are going to help us solve TCP global 26 01:13.060 --> 01:14.560 synchronization. 27 01:14.560 --> 01:19.230 Even though in the modern network, our focus is on red with a W here, we are 28 01:19.230 --> 01:20.000 primarily 29 01:20.000 --> 01:24.120 still going to be able to solve this problem with either one. 30 01:24.120 --> 01:28.550 Now this leads us to point number two here, challenge number two, where the 31 01:28.550 --> 01:29.440 organization 32 01:29.440 --> 01:34.920 is mapping these three different packet tags to a single queue. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:29.440 --> 01:34.920 is mapping these three different packet tags to a single queue. 33 01:34.920 --> 01:40.200 So AF for X essentially, so 41, 42 and 43. 34 01:40.200 --> 01:45.020 And remember, the higher priority actually exists up here with 41, meaning that 35 01:45.020 --> 01:45.560 we don't 36 01:45.560 --> 01:47.640 want to drop those packets. 37 01:47.640 --> 01:52.120 That's typically what we're talking about with those DSCP per hot behaviors. 38 01:52.120 --> 01:57.350 So what technique can be applied to ensure that we are not dropping 41 very 39 01:57.350 --> 01:58.080 often? 40 01:58.080 --> 02:00.680 Well, that's again, red with a W. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 40 01:58.080 --> 02:00.680 Well, that's again, red with a W. 41 02:00.680 --> 02:05.360 The weighted nature allows us to look at it and set individual thresholds. 42 02:05.360 --> 02:13.440 So now we're dropping 43 packets before we drop 42 packets and 42 before 41. 43 02:13.440 --> 02:16.120 Number three, and internet circuits being upgraded. 44 02:16.120 --> 02:19.440 So we have this situation, classic situation. 45 02:19.440 --> 02:24.310 We've got maybe our network core, and then we're connecting up to an internet 46 02:24.310 --> 02:25.160 circuit. 47 02:25.160 --> 02:27.780 Maybe it's going through some firewalls, hopefully it's going through some fire 48 02:27.780 --> 02:28.200 walls, 49 02:28.200 --> 02:29.760 or a couple of internet routers. 50 02:29.760 --> 02:32.680 But either way, we have an ISP device here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 50 02:29.760 --> 02:32.680 But either way, we have an ISP device here. 51 02:32.680 --> 02:38.650 We are handing off via one gigabit per second, but we have a policy that we 52 02:38.650 --> 02:39.400 have to meet, 53 02:39.400 --> 02:43.840 which is 250 megabits per second. 54 02:43.840 --> 02:49.270 Well, if the speed is one gigabit per second, from an ISP perspective, we know 55 02:49.270 --> 02:51.160 that the downstream 56 02:51.160 --> 02:54.400 client could be sending us the full one gig. 57 02:54.400 --> 02:55.920 And we do not want to allow that. 58 02:55.920 --> 02:59.120 We want to drop anything in excess of our policy. 59 02:59.120 --> 03:04.950 So this challenge question is just basically asking us from a basic perspective WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 59 02:59.120 --> 03:04.950 So this challenge question is just basically asking us from a basic perspective 60 03:04.950 --> 03:05.920 I met, 61 03:05.920 --> 03:11.950 is asking us what mechanism is being used here, what technique, and it is using 62 03:11.950 --> 03:13.000 policing. 63 03:13.000 --> 03:17.550 Now we don't have to go any deeper than that, but understand that we're 64 03:17.550 --> 03:19.040 probably deploying 65 03:19.040 --> 03:23.800 that token bucket policy, or that token bucket type of mechanism. 66 03:23.800 --> 03:31.060 And we probably have the concept of conforming traffic, as well as exceeding WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 66 03:23.800 --> 03:31.060 And we probably have the concept of conforming traffic, as well as exceeding 67 03:31.060 --> 03:32.280 traffic, where 68 03:32.280 --> 03:35.980 the conform action would be to allow the traffic and the exceed action would be 69 03:35.980 --> 03:36.640 probably in 70 03:36.640 --> 03:39.280 this case to drop the traffic. 71 03:39.280 --> 03:45.540 Now, number four, I guess I didn't write the word number three there, there we 72 03:45.540 --> 03:46.120 go. 73 03:46.120 --> 03:51.930 So number four, what policy can the organization use to ensure that the ISP 74 03:51.930 --> 03:54.120 never drops a packet? 75 03:54.120 --> 03:57.040 Well the answer here would be shaping. 76 03:57.040 --> 04:01.870 So we might be getting a whole lot of traffic, I'll draw it down here again, a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 76 03:57.040 --> 04:01.870 So we might be getting a whole lot of traffic, I'll draw it down here again, a 77 04:01.870 --> 04:02.880 bunch of traffic 78 04:02.880 --> 04:07.600 coming in, and maybe we want to try to send 300 meg out this link. 79 04:07.600 --> 04:15.400 Well, if we can shape this, so take our 300 and shape it down to that 250, well 80 04:15.400 --> 04:16.000 now this 81 04:16.000 --> 04:19.670 router is never going to drop a single packet, it's just going to approve the 82 04:19.670 --> 04:20.800 250 megabits 83 04:20.800 --> 04:25.620 per second that's coming in, especially if we exactly match the token bucket 84 04:25.620 --> 04:26.360 policy that's 85 04:26.360 --> 04:28.480 being used on both sides. 86 04:28.480 --> 04:33.170 Now keep in mind that this means that we have to stop, or maybe the right word WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 86 04:28.480 --> 04:33.170 Now keep in mind that this means that we have to stop, or maybe the right word 87 04:33.170 --> 04:33.480 in this 88 04:33.480 --> 04:37.440 case is pause, we have to make sure we're not sending packets even though we've 89 04:37.440 --> 04:38.120 got packets 90 04:38.120 --> 04:41.590 ready at various times, which means on the back end here we might end up 91 04:41.590 --> 04:42.320 filling up our 92 04:42.320 --> 04:44.520 queues and dropping traffic. 93 04:44.520 --> 04:48.880 So if the queues are filling up, this is where we rely on our random early 94 04:48.880 --> 04:50.520 detects techniques 95 04:50.520 --> 04:56.050 in order to make sure that hopefully we're dropping the lower priority packets 96 04:56.050 --> 04:56.720 in those 97 04:56.720 --> 04:57.720 queues. 98 04:57.720 --> 05:01.940 So a lot of this comes together around this concept of dropping packets, just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 04:57.720 --> 05:01.940 So a lot of this comes together around this concept of dropping packets, just 99 05:01.940 --> 05:02.320 keep in 100 05:02.320 --> 05:06.870 mind the very start of this whole conversation, we set our goal is to make sure 101 05:06.870 --> 05:07.600 that we stay 102 05:07.600 --> 05:12.330 in control of the packet drops, we want to make sure that nobody else is 103 05:12.330 --> 05:13.640 dropping packets 104 05:13.640 --> 05:18.230 and we are very intentionally dropping the lowest priority packets that we can, 105 05:18.230 --> 05:18.600 and along 106 05:18.600 --> 05:22.520 the way we manage to solve TCP global synchronization. 107 05:22.520 --> 05:25.200 I hope this has been informative for you and I'd like to thank you for viewing.