WEBVTT 1 00:00.000 --> 00:05.560 Well here's what we know so far. We want to use this diff serve QOS model and 2 00:05.560 --> 00:10.760 because diff server lies on all of these different routers and switches working 3 00:10.760 --> 00:16.200 together we're going to need a way to identify and classify our traffic and so 4 00:16.200 --> 00:22.200 we are going to use marking or tagging of our packets. We have COS for that we 5 00:22.200 --> 00:26.720 have DSCP for that as our primary mechanisms with IP precedence being a 6 00:26.720 --> 00:32.790 legacy marking method but now what what are we going to do at this point WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 6 00:26.720 --> 00:32.790 legacy marking method but now what what are we going to do at this point 7 00:32.790 --> 00:33.080 because 8 00:33.080 --> 00:39.360 what we have is we have these devices that are receiving tagged traffic so 9 00:39.360 --> 00:39.640 again 10 00:39.640 --> 00:44.920 maybe we have a packet here a voice over IP packet tagged with DSCP EF 11 00:44.920 --> 00:51.040 expedited forwarding decimal value 46 and so that's coming into this router and 12 00:51.040 --> 00:54.920 we know that we've got a link upstream to the next router this is the next 13 00:54.920 --> 01:01.520 top interface and maybe this is a hundred meg connection and this is marked as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 13 00:54.920 --> 01:01.520 top interface and maybe this is a hundred meg connection and this is marked as 14 01:01.520 --> 01:01.680 a 15 01:01.680 --> 01:08.320 very high priority type of packet so what do we do what kinds of policies can 16 01:08.320 --> 01:08.520 we 17 01:08.520 --> 01:14.120 be deploying against this traffic well the one we often cite is the concept of 18 01:14.120 --> 01:19.880 reservation and specifically we're talking about bandwidth reservation at 19 01:19.880 --> 01:25.040 this point so we just mentioned we have a hundred meg there we might want to 20 01:25.040 --> 01:32.320 reserve let's say one megabit per second for voice over IP so that'd be one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 20 01:25.040 --> 01:32.320 reserve let's say one megabit per second for voice over IP so that'd be one 21 01:32.320 --> 01:37.400 percent of that link now that doesn't sound like much at first one percent one 22 01:37.400 --> 01:42.560 megabit per second however keep in mind that voice over IP streams are usually 23 01:42.560 --> 01:49.200 64 kilobits per second it depends on the codec the way that we are encoding our 24 01:49.200 --> 01:56.320 analog voice communications into the digital world but usually we can think of 25 01:56.320 --> 02:00.560 them as being about 64 kilobits per second so we could get about 10 to 15 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 25 01:56.320 --> 02:00.560 them as being about 64 kilobits per second so we could get about 10 to 15 26 02:00.560 --> 02:05.160 calls on one megabit per second if this is a small branch office we don't have 27 02:05.160 --> 02:05.200 a 28 02:05.200 --> 02:10.760 whole lot of phones over here and so 10 to 15 simultaneous calls is probably 29 02:10.760 --> 02:15.560 sufficient now if this is a major headquarters connection that goes to 30 02:15.560 --> 02:20.650 another major headquarters then 10 to 15 might not be enough but naturally that 31 02:20.650 --> 02:20.720 's 32 02:20.720 --> 02:26.120 going to be a conversation depending on the scenario so either way we 33 02:26.120 --> 02:26.520 understand 34 02:26.520 --> 02:30.400 that we want to reserve some bandwidth we might also reserve bandwidth for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 34 02:26.520 --> 02:30.400 that we want to reserve some bandwidth we might also reserve bandwidth for 35 02:30.400 --> 02:35.080 other applications maybe we want to take 10 megabits per second and reserve 36 02:35.080 --> 02:35.240 that 37 02:35.240 --> 02:39.200 for video maybe that's not quite enough maybe it's plenty again depends on the 38 02:39.200 --> 02:42.720 situation we could always go with a percentage maybe we say let's just 39 02:42.720 --> 02:47.880 reserve 20% of the link that would give us 20 megabits per second on that 100 40 02:47.880 --> 02:53.000 meg connection something along those lines so bandwidth reservation is great 41 02:53.000 --> 02:58.720 but it's not enough we also need to consider the concept of traffic 42 02:58.720 --> 03:06.800 prioritization so we need to be able to prioritize traffic this is the second WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 02:58.720 --> 03:06.800 prioritization so we need to be able to prioritize traffic this is the second 43 03:06.800 --> 03:12.480 part of our Qs conversations and the prioritization of traffic is going to 44 03:12.480 --> 03:18.480 come down to a couple of different factors first of all the order in which 45 03:18.480 --> 03:26.120 we send packets so order for transmitting packets here and we also have to 46 03:26.120 --> 03:31.800 consider the order of magnitude or the likelihood you know the probability WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 46 03:26.120 --> 03:31.800 consider the order of magnitude or the likelihood you know the probability 47 03:31.800 --> 03:40.920 we want to say it we'll say the likelihood here of dropping packets so 48 03:40.920 --> 03:45.240 let's look at these in a little bit more detail so we just said that we want to 49 03:45.240 --> 03:50.440 reserve traffic and we maybe have reserved one megabit per second and 50 03:50.440 --> 03:55.000 we're making the claim that that's not enough well that's not enough and here's 51 03:55.000 --> 04:03.360 why what happens if we have this router and we have this interface and yeah we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 51 03:55.000 --> 04:03.360 why what happens if we have this router and we have this interface and yeah we 52 04:03.360 --> 04:07.600 are sending out on a hundred megabit per second connection we want to reserve 53 04:07.600 --> 04:12.480 that but what if we're just sitting here at about 25 out of the hundred megab 54 04:12.480 --> 04:12.640 its 55 04:12.640 --> 04:18.640 per second well we're not full at all and if we're not full that means that the 56 04:18.640 --> 04:22.640 bandwidth reservation doesn't actually mean anything I mean voice over IP could 57 04:22.640 --> 04:28.280 take 75 megabits per second if needed on this link because that's how much is 58 04:28.280 --> 04:33.120 available so that's all well and good but at this point we have bulk traffic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 58 04:28.280 --> 04:33.120 available so that's all well and good but at this point we have bulk traffic 59 04:33.120 --> 04:39.560 coming through then we have voice over IP and video traffic and this router is 60 04:39.560 --> 04:47.120 going to view all of these traffic types as the same yeah if we were full on 61 04:47.120 --> 04:47.320 the 62 04:47.320 --> 04:50.600 bandwidth then we would make sure we keep some of that set aside so that 63 04:50.600 --> 04:55.360 video traffic could get through and voice traffic could get through but at 64 04:55.360 --> 04:59.520 this point we're saying that well if everything is fine we're just going to 65 04:59.520 --> 05:04.720 send traffic in the order we received it well what if we have a lot of bulk WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 65 04:59.520 --> 05:04.720 send traffic in the order we received it well what if we have a lot of bulk 66 05:04.720 --> 05:09.000 traffic that's stacked up when I say bulk traffic I mean transferring data 67 05:09.000 --> 05:14.640 downloading from the internet and internet stream these types of traffic 68 05:14.640 --> 05:20.560 flows they are not based on real-time applications so this is where we 69 05:20.560 --> 05:26.520 said before that if we had you know an increase in 500 milliseconds for one of 70 05:26.520 --> 05:30.560 these types of applications I mean nobody's going to notice if there's a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 05:26.520 --> 05:30.560 these types of applications I mean nobody's going to notice if there's a 71 05:30.560 --> 05:34.240 half a second delay on the amount of time it takes me to download a file from 72 05:34.240 --> 05:40.080 the internet but if we have an increase in 500 of 500 milliseconds rather for 73 05:40.080 --> 05:45.400 voice and video calls that lag is going to be very noticeable and so these are 74 05:45.400 --> 05:49.520 considered to be real-time applications and there are other real-time 75 05:49.520 --> 05:50.260 applications 76 05:50.260 --> 05:56.200 that exist as well so this is where we care about the order of transmission if 77 05:56.200 --> 06:01.240 I've got a bunch of this bulk packets stacked up and a video packet shows up or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 05:56.200 --> 06:01.240 I've got a bunch of this bulk packets stacked up and a video packet shows up or 78 06:01.240 --> 06:05.480 a voice packet shows up I would want to push that to the front of the line and 79 06:05.480 --> 06:10.080 have it get sent first so the order of the transmitted packets matters 80 06:10.080 --> 06:15.400 furthermore if this router gets so overwhelmed that it now needs to start 81 06:15.400 --> 06:21.060 dropping traffic well that can actually happen as well so we might just be 82 06:21.060 --> 06:25.740 maxed out on the ingress we might be maxed out an internal buffer there's a lot 83 06:25.740 --> 06:31.180 of ways we can get overwhelmed as a network device and so we have to choose WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 83 06:25.740 --> 06:31.180 of ways we can get overwhelmed as a network device and so we have to choose 84 06:31.180 --> 06:40.540 which traffic to drop in fact so often when it comes to talking about quality 85 06:40.540 --> 06:45.300 of service sometimes it makes it feel like what we're saying is that we 86 06:45.300 --> 06:49.440 can make sure that we don't ever drop any traffic with QOS and that's 87 06:49.440 --> 06:53.580 absolutely not the case the better way to describe QOS is to say that we're 88 06:53.580 --> 06:56.640 going to choose which traffic to drop we're going to choose the order of our 89 06:56.640 --> 07:01.720 packets I can't magically make this hundred megabits per second into 200 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 06:56.640 --> 07:01.720 packets I can't magically make this hundred megabits per second into 200 90 07:01.720 --> 07:05.440 megabits per second it just doesn't work that way sure we could use some 91 07:05.440 --> 07:09.560 compression techniques and things like that to maximize our efficiency but we 92 07:09.560 --> 07:13.880 don't really use those anymore because we've got a lot of bandwidth we just 93 07:13.880 --> 07:14.040 have 94 07:14.040 --> 07:18.820 to make sure we're making the most of it I'm not talking about T1s and ISDN 95 07:18.820 --> 07:19.100 lines 96 07:19.100 --> 07:23.800 anymore which are you know way way smaller and as far as bandwidth is 97 07:23.800 --> 07:27.400 concerned so if we're going to choose what type of traffic to drop well now 98 07:27.400 --> 07:33.280 that comes back to our ability to prioritize different traffic flows so WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 07:27.400 --> 07:33.280 that comes back to our ability to prioritize different traffic flows so 99 07:33.280 --> 07:38.720 all of this is going to come down to a QOS technique that's known as congestion 100 07:38.720 --> 07:45.320 management congestion management is ultimately taking the concept of Qs and 101 07:45.320 --> 07:50.080 making it so that we sort our traffic into different Qs and then we schedule 102 07:50.080 --> 07:53.200 traffic to be sent out of those respective Qs so we're going to be 103 07:53.200 --> 07:57.040 diving into the details of that but just like we had with classification and 104 07:57.040 --> 08:01.720 marking we do have a little bit more of a formal way of talking about queuing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 104 07:57.040 --> 08:01.720 marking we do have a little bit more of a formal way of talking about queuing 105 08:01.720 --> 08:01.880 and 106 08:01.880 --> 08:06.560 scheduling and that in the QOS world is congestion management so let's go ahead 107 08:06.560 --> 08:08.980 and dive into that whole new concept.