WEBVTT 1 00:00.000 --> 00:03.880 All right, let's take a moment, answer these questions together and just make 2 00:03.880 --> 00:04.200 sure that 3 00:04.200 --> 00:08.640 we've got all of this down as far as the major topics that we've discussed. 4 00:08.640 --> 00:13.020 We are laying the groundwork for why QOS is so important as well as how we can 5 00:13.020 --> 00:13.440 kind of 6 00:13.440 --> 00:17.360 measure the success of whether our QOS is working. 7 00:17.360 --> 00:20.840 And from here, we're going to launch ourselves into all the mechanisms we have 8 00:20.840 --> 00:21.360 to deploy 9 00:21.360 --> 00:23.960 in order to make QOS work. 10 00:23.960 --> 00:27.880 So to start off with, match the traffic type to their classifications. 11 00:27.880 --> 00:31.480 So we need a mission critical time-sensitive application. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:27.880 --> 00:31.480 So we need a mission critical time-sensitive application. 12 00:31.480 --> 00:34.040 That would be voiceover IP and video. 13 00:34.040 --> 00:36.160 Time-sensitive is the key word there. 14 00:36.160 --> 00:39.750 A non-critical example would probably be internet streaming and then the 15 00:39.750 --> 00:40.880 mission critical, but 16 00:40.880 --> 00:41.880 not time-sensitive. 17 00:41.880 --> 00:45.560 Remember, we gave an example of those data center live migrations. 18 00:45.560 --> 00:46.960 That would be a great concept here. 19 00:46.960 --> 00:52.280 We don't need to prioritize that traffic over voiceover IP, for example. 20 00:52.280 --> 00:55.880 But we do want it to happen in a timely fashion and so we'd give some 21 00:55.880 --> 00:57.200 reservations around 22 00:57.200 --> 01:01.790 it, but we don't need to worry about whether or not it's going to make it an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 22 00:57.200 --> 01:01.790 it, but we don't need to worry about whether or not it's going to make it an 23 01:01.790 --> 01:02.880 extra 500 24 01:02.880 --> 01:04.520 milliseconds or not. 25 01:04.520 --> 01:07.160 Now match the concepts to the QOS model. 26 01:07.160 --> 01:10.120 Remember, diff-serve and int-serve are two different models. 27 01:10.120 --> 01:14.890 We have an upside for diff-serve and we're looking at the upside for diff-serve 28 01:14.890 --> 01:15.240 . 29 01:15.240 --> 01:18.380 This is the model that we use in our modern networks. 30 01:18.380 --> 01:22.160 The biggest advantage is the fact that bandwidth is efficiently used. 31 01:22.160 --> 01:26.890 The mechanism we use for this is not reserving bandwidth, but it's actually 32 01:26.890 --> 01:28.120 tagging our packets 33 01:28.120 --> 01:30.400 and doing those per-hot behaviors. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 33 01:28.120 --> 01:30.400 and doing those per-hot behaviors. 34 01:30.400 --> 01:36.600 Int-serve, meanwhile, only wants to emulate those old circuit-style networks 35 01:36.600 --> 01:37.040 and so we 36 01:37.040 --> 01:43.850 are going to perform the mechanism here is the resource reservations using RSVP 37 01:43.850 --> 01:44.360 and the 38 01:44.360 --> 01:48.600 upside is that bandwidth is fully reserved. 39 01:48.600 --> 01:52.200 Next what is the Cisco recommended voiceover IP threshold? 40 01:52.200 --> 01:55.000 So now we're going to vault into these three different metrics. 41 01:55.000 --> 01:58.630 Want to make sure that we know what the recommended thresholds are for each one 42 01:58.630 --> 01:59.600 of these. 43 01:59.600 --> 02:02.240 The one-way latency, don't be fooled here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 43 01:59.600 --> 02:02.240 The one-way latency, don't be fooled here. 44 02:02.240 --> 02:06.920 Remember, the one-way latency is 150 milliseconds, not 300. 45 02:06.920 --> 02:12.710 Recall that if we're going to test round trip time or RTT, it might go in 150 46 02:12.710 --> 02:13.840 milliseconds 47 02:13.840 --> 02:19.220 this way and 150 milliseconds that way and we might say okay, well that's 300 48 02:19.220 --> 02:20.240 milliseconds, 49 02:20.240 --> 02:25.080 but even if we have an RTT of 250 milliseconds, that might be problematic. 50 02:25.080 --> 02:29.040 What if it was 50 milliseconds one way and 200 coming back? 51 02:29.040 --> 02:32.490 Well that would exceed the one-way latency requirements and so that's why we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 51 02:29.040 --> 02:32.490 Well that would exceed the one-way latency requirements and so that's why we 52 02:32.490 --> 02:33.000 always have 53 02:33.000 --> 02:35.600 to test one-way as best we can. 54 02:35.600 --> 02:40.240 What is the Cisco recommended voiceover IP threshold for the average jitter? 55 02:40.240 --> 02:46.360 It's also measured in milliseconds and again it's comparing the differences in 56 02:46.360 --> 02:48.200 our latency. 57 02:48.200 --> 02:51.990 So 30 milliseconds is the threshold for jitter, it's just something we're going 58 02:51.990 --> 02:52.400 to have to 59 02:52.400 --> 02:53.480 remember. 60 02:53.480 --> 02:58.750 And lastly what is the Cisco recommended voiceover IP threshold for packet loss 61 02:58.750 --> 02:58.840 ? 62 02:58.840 --> 03:03.250 Well it doesn't sound like much, it's 1% and yeah, I mean when we're talking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 62 02:58.840 --> 03:03.250 Well it doesn't sound like much, it's 1% and yeah, I mean when we're talking 63 03:03.250 --> 03:04.440 about voiceover 64 03:04.440 --> 03:09.630 IP, we need to make sure that we keep as many of those packets alive as 65 03:09.630 --> 03:10.920 possible, even dropping 66 03:10.920 --> 03:17.160 1% of our voiceover IP packets can result in a noticeable slip of that mean 67 03:17.160 --> 03:17.920 opinion 68 03:17.920 --> 03:19.320 score MOS. 69 03:19.320 --> 03:24.120 So let's make sure that we've got those different measurements down as far as 70 03:24.120 --> 03:24.920 how we measure 71 03:24.920 --> 03:29.180 them and what those thresholds are as well as understanding that we're going to 72 03:29.180 --> 03:29.720 be vaulting 73 03:29.720 --> 03:33.440 into the diff serve model and learning how exactly that all comes together. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 73 03:29.720 --> 03:33.440 into the diff serve model and learning how exactly that all comes together. 74 03:33.440 --> 03:36.120 I hope this has been informative for you and I'd like to thank you for viewing.