WEBVTT

1
00:00.000 --> 00:04.800
So it's great to say that we want a better quality of experience, but what are

2
00:04.800 --> 00:06.000
we really talking about?

3
00:06.000 --> 00:10.460
It's important for us to define the different metrics on the network that we're

4
00:10.460 --> 00:14.300
going to use to tell whether or not we've been successful in improving the

5
00:14.300 --> 00:16.000
overall experience.

6
00:16.000 --> 00:20.390
Because yeah, we could ask users, but that's usually rooted in opinion, and we

7
00:20.390 --> 00:23.000
want something a little bit more solid and data-driven.

8
00:23.000 --> 00:28.660
So the first metric we're going to look at is latency, otherwise known as delay

9
00:28.660 --> 00:29.000
.

10
00:29.000 --> 00:34.350
Any time we do a ping on a network device, it tells us how long it takes for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:29.000 --> 00:34.350
Any time we do a ping on a network device, it tells us how long it takes for

11
00:34.350 --> 00:37.000
that packet to go to its destination and come back.

12
00:37.000 --> 00:42.000
And the amount of time that takes is the latency or the delay.

13
00:42.000 --> 00:48.750
Now, this can also be known importantly as round trip time or RTT, keeping in

14
00:48.750 --> 00:53.000
mind that round trip time involves exactly what I just said.

15
00:53.000 --> 00:58.560
I send a packet out to a device and it responds, and so when we're talking

16
00:58.560 --> 01:03.970
about latency, we need to know, are we talking about round trip time or are we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

16
00:58.560 --> 01:03.970
about latency, we need to know, are we talking about round trip time or are we

17
01:03.970 --> 01:07.000
talking about one way?

18
01:07.000 --> 01:13.460
One way latency would involve just one of these trips, round trip time would

19
01:13.460 --> 01:16.000
involve both of the trips.

20
01:16.000 --> 01:21.670
Now, latency on a LAN is probably going to be ideally less than 10 milliseconds

21
01:21.670 --> 01:22.000
.

22
01:22.000 --> 01:25.540
If we're talking about directly connected devices and the network is in good

23
01:25.540 --> 01:29.000
shape, it should probably even be under one millisecond.

24
01:29.000 --> 01:34.100
But when we're talking about a wide area network circuit, we don't always have
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

24
01:29.000 --> 01:34.100
But when we're talking about a wide area network circuit, we don't always have

25
01:34.100 --> 01:38.000
a lot of control over what's happening on the service provider network,

26
01:38.000 --> 01:44.000
and therefore we might actually see this as tens or hundreds of milliseconds.

27
01:44.000 --> 01:48.500
But I will say this, notice, ideally we're measuring our latency in

28
01:48.500 --> 01:51.000
milliseconds and not actually full seconds.

29
01:51.000 --> 01:54.790
So if we do see this go up into the thousands of milliseconds, well, that's no

30
01:54.790 --> 01:58.000
longer milliseconds, that's just regular seconds.

31
01:58.000 --> 02:00.000
Now, we'd want to avoid that.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

32
02:00.000 --> 02:03.250
Now, when we're talking about voice over IP and we'll relate a lot of this back

33
02:03.250 --> 02:07.140
to voice over IP because, again, when we're talking about quality of service in

34
02:07.140 --> 02:13.000
the real world, we're typically trying to address voice over IP especially.

35
02:13.000 --> 02:15.000
Now, we're talking about this.

36
02:15.000 --> 02:20.640
We are typically going to want to keep our connections below 150 milliseconds

37
02:20.640 --> 02:27.000
of, and this part's important, one way latency.

38
02:27.000 --> 02:34.240
So, if I send a ping out and it takes 300 milliseconds, this might actually be
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

38
02:27.000 --> 02:34.240
So, if I send a ping out and it takes 300 milliseconds, this might actually be

39
02:34.240 --> 02:35.000
fine.

40
02:35.000 --> 02:39.000
It could be fine or it could actually not be fine.

41
02:39.000 --> 02:43.000
How do I know the difference? Well, it can be very difficult to tell the

42
02:43.000 --> 02:43.000
difference.

43
02:43.000 --> 02:49.340
If, for example, it's 151 way and 150 back, then we're good in theory, I guess

44
02:49.340 --> 02:54.370
maybe we'd want it to be 149, so it's below the 150, but if it's evenly divided

45
02:54.370 --> 02:55.000
, great.

46
02:55.000 --> 02:59.000
But what if it's 100 milliseconds one way and 200 milliseconds the other way?

47
02:59.000 --> 03:03.830
At that point, we can see that our one way latency in one of the directions is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
02:59.000 --> 03:03.830
At that point, we can see that our one way latency in one of the directions is

48
03:03.830 --> 03:05.000
problematic.

49
03:05.000 --> 03:09.830
So, if we do see that our round trip time is 300 milliseconds or maybe even

50
03:09.830 --> 03:15.650
approaching that, it's very likely one of those one way trips was actually

51
03:15.650 --> 03:18.000
greater than that 150 milliseconds.

52
03:18.000 --> 03:20.000
So, something to keep in mind there.

53
03:20.000 --> 03:24.780
Now, another big one, especially when we're looking at things from the voice

54
03:24.780 --> 03:27.000
world, is the concept of jitter.

55
03:27.000 --> 03:36.310
Jitter is very interesting. It's actually measured as the variation in delay or
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
03:27.000 --> 03:36.310
Jitter is very interesting. It's actually measured as the variation in delay or

56
03:36.310 --> 03:38.000
variation in latency.

57
03:38.000 --> 03:43.660
What on earth does that mean? Well, what it means is I'm going to attract the

58
03:43.660 --> 03:48.780
delay over the course of time and I'm going to take an average of the

59
03:48.780 --> 03:50.000
difference.

60
03:50.000 --> 04:00.000
All right, so let's take a look at this. So, let's say that I measure the one
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

63
04:00.000 --> 04:05.000
And then as that communication happens, I measure again and it took something

64
04:05.000 --> 04:10.000
like 12. And then down here, we had a measure of 2 milliseconds.

65
04:10.000 --> 04:14.000
And then back up here, we had a measure of 11.

66
04:14.000 --> 04:18.470
So, what's interesting about this is we might say, okay, this is great because

67
04:18.470 --> 04:21.000
it's all under 150 milliseconds.

68
04:21.000 --> 04:25.440
And in this scenario, those values are so low, we're probably on a local area

69
04:25.440 --> 04:29.000
network and jitter is not going to be a major problem.

70
04:29.000 --> 04:34.000
But notice this value right here. Notice how it shrunk down to 2 milliseconds.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
04:29.000 --> 04:34.000
But notice this value right here. Notice how it shrunk down to 2 milliseconds.

71
04:34.000 --> 04:39.100
What jitter can do for us is it can make it so that packets actually sort of

72
04:39.100 --> 04:41.000
catch up to each other.

73
04:41.000 --> 04:47.000
In other words, I'm expecting a regular cadence of packets such as this.

74
04:47.000 --> 04:52.360
And in reality, what happens is after that first packet arrives, yeah, the next

75
04:52.360 --> 04:55.000
one took 10 milliseconds.

76
04:55.000 --> 04:59.000
And the next one took 12 milliseconds, so it lagged a little bit behind.

77
04:59.000 --> 05:03.390
But then we had one that took 2 milliseconds to travel and then we had another
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
04:59.000 --> 05:03.390
But then we had one that took 2 milliseconds to travel and then we had another

78
05:03.390 --> 05:05.000
11 milliseconds.

79
05:05.000 --> 05:09.390
So we see that these packets can kind of cluster or become isolated from one

80
05:09.390 --> 05:13.000
another, and that creates a very jarring experience.

81
05:13.000 --> 05:20.000
And so this top version here has roughly zero jitter.

82
05:20.000 --> 05:25.000
Whereas down here, we actually have quite a bit of jitter.

83
05:25.000 --> 05:28.970
So on the surface, we might say, oh, great, we got to pack it through at 2

84
05:28.970 --> 05:32.250
milliseconds, and yet in this situation, it might have actually been
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
05:28.970 --> 05:32.250
milliseconds, and yet in this situation, it might have actually been

85
05:32.250 --> 05:33.000
problematic.

86
05:33.000 --> 05:37.290
Now, if we add a zero to all of these, and we're talking about 100 and 120 and

87
05:37.290 --> 05:44.000
110, and then 20, it becomes even more of a jarring experience to the end user

88
05:44.000 --> 05:48.000
if this is happening, or constantly throughout the phone call.

89
05:48.000 --> 05:51.000
And so how exactly do we measure jitter?

90
05:51.000 --> 05:55.770
Well, we're going to take all of these values here, and we're going to average

91
05:55.770 --> 05:58.000
it out over the course of time.

92
05:58.000 --> 06:02.410
To measure jitter, we're actually going to look at the intervals between our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
05:58.000 --> 06:02.410
To measure jitter, we're actually going to look at the intervals between our

93
06:02.410 --> 06:04.000
different measurements.

94
06:04.000 --> 06:09.000
So, for example, we started with 10 milliseconds, and we went up to 12.

95
06:09.000 --> 06:13.000
So this would be a 2 millisecond difference in latency.

96
06:13.000 --> 06:16.000
And then we get down from 12 all the way down to 2.

97
06:16.000 --> 06:22.000
So that would be a 10 milliseconds of a, again, variation in latency.

98
06:22.000 --> 06:26.800
And then we go all the way back up to 11, and that is a 9 millisecond

99
06:26.800 --> 06:28.000
measurement.

100
06:28.000 --> 06:30.000
So we're going to add all of this together.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
06:30.000 --> 06:34.510
That adds up to 21 milliseconds divided by the number of data points, which is

102
06:34.510 --> 06:35.000
3.

103
06:35.000 --> 06:40.000
And this gives us an average of 7 milliseconds of jitter.

104
06:40.000 --> 06:44.000
And yes, jitter is measured in milliseconds.

105
06:44.000 --> 06:48.160
Now, we can also look at this and say the max jitter was 10 milliseconds, and

106
06:48.160 --> 06:50.000
so we might take a look at that metric.

107
06:50.000 --> 06:55.310
But again, we're really looking at overall the average from an experienced

108
06:55.310 --> 06:56.000
perspective,

109
06:56.000 --> 06:59.000
and 7 milliseconds of jitter is actually pretty good.

110
06:59.000 --> 07:03.000
Going back to voiceover IP, what's the expectation?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

110
06:59.000 --> 07:03.000
Going back to voiceover IP, what's the expectation?

111
07:03.000 --> 07:08.000
Well, we want it to be less than 30 milliseconds for voiceover IP calls.

112
07:08.000 --> 07:14.000
So even though, yeah, it went from 12 and 10 down to 2, that's perfectly fine.

113
07:14.000 --> 07:19.420
But again, if we had added zeros and there's 120 and 100 here and 110, well,

114
07:19.420 --> 07:24.140
now we see that that might actually result in a jitter that's noticeable to the

115
07:24.140 --> 07:25.000
human ear.

116
07:25.000 --> 07:27.770
Now, when we're talking about these recommendations, by the way, some of these

117
07:27.770 --> 07:31.000
are industry recommendations, but they're also all Cisco recommendations.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
07:27.770 --> 07:31.000
are industry recommendations, but they're also all Cisco recommendations.

118
07:31.000 --> 07:38.820
So Cisco wants less than 150 milliseconds of latency, one way, and less than 30

119
07:38.820 --> 07:41.000
milliseconds of jitter.

120
07:41.000 --> 07:45.000
When we're talking about their recommendations for voiceover IP.

121
07:45.000 --> 07:51.000
Now, next we can talk about the concept of packet loss.

122
07:51.000 --> 07:55.340
Packet losses just when we lose packets on the network, which happens a lot in

123
07:55.340 --> 07:57.000
packet switch networks.

124
07:57.000 --> 07:59.000
So what causes packet loss?

125
07:59.000 --> 08:04.370
Well, a lot of things congestion certainly is going to cause packet loss when
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
07:59.000 --> 08:04.370
Well, a lot of things congestion certainly is going to cause packet loss when

126
08:04.370 --> 08:07.000
we have full filled up buffers.

127
08:07.000 --> 08:10.000
Too many packets to send devices will start dropping them.

128
08:10.000 --> 08:13.000
That's probably the number one cause in our network.

129
08:13.000 --> 08:17.270
But never leave out the possibility of something like a bad connection,

130
08:17.270 --> 08:19.000
especially if it's Wi-Fi.

131
08:19.000 --> 08:23.960
If it's a wireless connection, that can cause a lot of packet loss simply

132
08:23.960 --> 08:27.650
because wireless, even though a packet will eventually get through on the

133
08:27.650 --> 08:32.200
wireless, we might actually find that it arrives too late and that's considered
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
08:27.650 --> 08:32.200
wireless, we might actually find that it arrives too late and that's considered

134
08:32.200 --> 08:33.000
packet loss as well.

135
08:33.000 --> 08:38.000
We might have problems like malformed packets.

136
08:38.000 --> 08:41.460
That's not super common, but if we have a bad nick, then certainly that could

137
08:41.460 --> 08:43.000
cause a whole lot of packet loss.

138
08:43.000 --> 08:45.000
It's something we need to consider.

139
08:45.000 --> 08:49.270
And so that could also be a conversation around actual hardware failure,

140
08:49.270 --> 08:54.000
whether that's on the network or on the network interface card on the device.

141
08:54.000 --> 08:56.000
So we want to keep packet loss low.

142
08:56.000 --> 09:02.000
Cisco recommends less than 1% packet loss for voiceover IP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

142
08:56.000 --> 09:02.000
Cisco recommends less than 1% packet loss for voiceover IP.

143
09:02.000 --> 09:08.600
Now, lastly, when we're talking about voiceover IP, we're going to take these

144
09:08.600 --> 09:15.000
three different metrics and these three different metrics of latency and jitter

145
09:15.000 --> 09:17.000
and packet loss.

146
09:17.000 --> 09:26.170
These combine into a concept known as the mean opinion score, otherwise known

147
09:26.170 --> 09:28.000
as MOS.

148
09:28.000 --> 09:33.300
The MOS for a traffic flow, and this is especially used in the voiceover IP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

148
09:28.000 --> 09:33.300
The MOS for a traffic flow, and this is especially used in the voiceover IP

149
09:33.300 --> 09:40.000
world, is a range of 0 to 5 and it measures the call quality.

150
09:40.000 --> 09:44.500
Now, the reasons called mean opinion scores, because this used to be the

151
09:44.500 --> 09:46.000
opinion of the user.

152
09:46.000 --> 09:48.000
We'd ask the user for their opinions.

153
09:48.000 --> 09:52.200
They'd rate the phone call and then over the course of time, we'd build out an

154
09:52.200 --> 09:56.000
average MOS for a particular phone environment.

155
09:56.000 --> 09:59.000
Well, nowadays, we don't ask anybody anything.

156
09:59.000 --> 10:02.000
We just look at these metrics.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
09:59.000 --> 10:02.000
We just look at these metrics.

157
10:02.000 --> 10:07.490
And so we can look in typically a Cisco call manager or something along those

158
10:07.490 --> 10:12.750
lines and we can see based on the metrics that we're collecting what the MOS is

159
10:12.750 --> 10:13.000
.

160
10:13.000 --> 10:16.960
If we have an MOS of 4.75 on the network, then we're in really good shape and

161
10:16.960 --> 10:18.000
that's awesome.

162
10:18.000 --> 10:22.580
If we're dropping down into the 3.5 range, well, we might have some concerns

163
10:22.580 --> 10:24.000
that we'd need to address.

164
10:24.000 --> 10:29.260
We're not going to worry about the formula for taking these metrics and

165
10:29.260 --> 10:33.840
collecting them and determining what the mean opinion score is, but we should
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

165
10:29.260 --> 10:33.840
collecting them and determining what the mean opinion score is, but we should

166
10:33.840 --> 10:41.000
know that it ranges from 0 to 5 and it reflects these 3 specific metrics.