So it's great to say that we want a better quality of experience, but what are
we really talking about?
It's important for us to define the different metrics on the network that we're
going to use to tell whether or not we've been successful in improving the
overall experience.
Because yeah, we could ask users, but that's usually rooted in opinion, and we
want something a little bit more solid and data-driven.
So the first metric we're going to look at is latency, otherwise known as delay
.
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
Any time we do a ping on a network device, it tells us how long it takes for
that packet to go to its destination and come back.
And the amount of time that takes is the latency or the delay.
Now, this can also be known importantly as round trip time or RTT, keeping in
mind that round trip time involves exactly what I just said.
I send a packet out to a device and it responds, and so when we're talking
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
about latency, we need to know, are we talking about round trip time or are we
talking about one way?
One way latency would involve just one of these trips, round trip time would
involve both of the trips.
Now, latency on a LAN is probably going to be ideally less than 10 milliseconds
.
If we're talking about directly connected devices and the network is in good
shape, it should probably even be under one millisecond.
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
But when we're talking about a wide area network circuit, we don't always have
a lot of control over what's happening on the service provider network,
and therefore we might actually see this as tens or hundreds of milliseconds.
But I will say this, notice, ideally we're measuring our latency in
milliseconds and not actually full seconds.
So if we do see this go up into the thousands of milliseconds, well, that's no
longer milliseconds, that's just regular seconds.
Now, we'd want to avoid that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, when we're talking about voice over IP and we'll relate a lot of this back
to voice over IP because, again, when we're talking about quality of service in
the real world, we're typically trying to address voice over IP especially.
Now, we're talking about this.
We are typically going to want to keep our connections below 150 milliseconds
of, and this part's important, one way latency.
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
So, if I send a ping out and it takes 300 milliseconds, this might actually be
fine.
It could be fine or it could actually not be fine.
How do I know the difference? Well, it can be very difficult to tell the
difference.
If, for example, it's 151 way and 150 back, then we're good in theory, I guess
maybe we'd want it to be 149, so it's below the 150, but if it's evenly divided
, great.
But what if it's 100 milliseconds one way and 200 milliseconds the other way?
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
At that point, we can see that our one way latency in one of the directions is
problematic.
So, if we do see that our round trip time is 300 milliseconds or maybe even
approaching that, it's very likely one of those one way trips was actually
greater than that 150 milliseconds.
So, something to keep in mind there.
Now, another big one, especially when we're looking at things from the voice
world, is the concept of jitter.
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
Jitter is very interesting. It's actually measured as the variation in delay or
variation in latency.
What on earth does that mean? Well, what it means is I'm going to attract the
delay over the course of time and I'm going to take an average of the
difference.
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
And then as that communication happens, I measure again and it took something
like 12. And then down here, we had a measure of 2 milliseconds.
And then back up here, we had a measure of 11.
So, what's interesting about this is we might say, okay, this is great because
it's all under 150 milliseconds.
And in this scenario, those values are so low, we're probably on a local area
network and jitter is not going to be a major problem.
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
But notice this value right here. Notice how it shrunk down to 2 milliseconds.
What jitter can do for us is it can make it so that packets actually sort of
catch up to each other.
In other words, I'm expecting a regular cadence of packets such as this.
And in reality, what happens is after that first packet arrives, yeah, the next
one took 10 milliseconds.
And the next one took 12 milliseconds, so it lagged a little bit behind.
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
But then we had one that took 2 milliseconds to travel and then we had another
11 milliseconds.
So we see that these packets can kind of cluster or become isolated from one
another, and that creates a very jarring experience.
And so this top version here has roughly zero jitter.
Whereas down here, we actually have quite a bit of jitter.
So on the surface, we might say, oh, great, we got to pack it through at 2
milliseconds, and yet in this situation, it might have actually been WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
milliseconds, and yet in this situation, it might have actually been
problematic.
Now, if we add a zero to all of these, and we're talking about 100 and 120 and
110, and then 20, it becomes even more of a jarring experience to the end user
if this is happening, or constantly throughout the phone call.
And so how exactly do we measure jitter?
Well, we're going to take all of these values here, and we're going to average
it out over the course of time.
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
To measure jitter, we're actually going to look at the intervals between our
different measurements.
So, for example, we started with 10 milliseconds, and we went up to 12.
So this would be a 2 millisecond difference in latency.
And then we get down from 12 all the way down to 2.
So that would be a 10 milliseconds of a, again, variation in latency.
And then we go all the way back up to 11, and that is a 9 millisecond
measurement.
So we're going to add all of this together. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That adds up to 21 milliseconds divided by the number of data points, which is
3.
And this gives us an average of 7 milliseconds of jitter.
And yes, jitter is measured in milliseconds.
Now, we can also look at this and say the max jitter was 10 milliseconds, and
so we might take a look at that metric.
But again, we're really looking at overall the average from an experienced
perspective,
and 7 milliseconds of jitter is actually pretty good.
Going back to voiceover IP, what's the expectation? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Going back to voiceover IP, what's the expectation?
Well, we want it to be less than 30 milliseconds for voiceover IP calls.
So even though, yeah, it went from 12 and 10 down to 2, that's perfectly fine.
But again, if we had added zeros and there's 120 and 100 here and 110, well,
now we see that that might actually result in a jitter that's noticeable to the
human ear.
Now, when we're talking about these recommendations, by the way, some of these
are industry recommendations, but they're also all Cisco recommendations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are industry recommendations, but they're also all Cisco recommendations.
So Cisco wants less than 150 milliseconds of latency, one way, and less than 30
milliseconds of jitter.
When we're talking about their recommendations for voiceover IP.
Now, next we can talk about the concept of packet loss.
Packet losses just when we lose packets on the network, which happens a lot in
packet switch networks.
So what causes packet loss?
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
Well, a lot of things congestion certainly is going to cause packet loss when
we have full filled up buffers.
Too many packets to send devices will start dropping them.
That's probably the number one cause in our network.
But never leave out the possibility of something like a bad connection,
especially if it's Wi-Fi.
If it's a wireless connection, that can cause a lot of packet loss simply
because wireless, even though a packet will eventually get through on the
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
wireless, we might actually find that it arrives too late and that's considered
packet loss as well.
We might have problems like malformed packets.
That's not super common, but if we have a bad nick, then certainly that could
cause a whole lot of packet loss.
It's something we need to consider.
And so that could also be a conversation around actual hardware failure,
whether that's on the network or on the network interface card on the device.
So we want to keep packet loss low.
Cisco recommends less than 1% packet loss for voiceover IP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Cisco recommends less than 1% packet loss for voiceover IP.
Now, lastly, when we're talking about voiceover IP, we're going to take these
three different metrics and these three different metrics of latency and jitter
and packet loss.
These combine into a concept known as the mean opinion score, otherwise known
as MOS.
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
The MOS for a traffic flow, and this is especially used in the voiceover IP
world, is a range of 0 to 5 and it measures the call quality.
Now, the reasons called mean opinion scores, because this used to be the
opinion of the user.
We'd ask the user for their opinions.
They'd rate the phone call and then over the course of time, we'd build out an
average MOS for a particular phone environment.
Well, nowadays, we don't ask anybody anything.
We just look at these metrics. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We just look at these metrics.
And so we can look in typically a Cisco call manager or something along those
lines and we can see based on the metrics that we're collecting what the MOS is
.
If we have an MOS of 4.75 on the network, then we're in really good shape and
that's awesome.
If we're dropping down into the 3.5 range, well, we might have some concerns
that we'd need to address.
We're not going to worry about the formula for taking these metrics and
collecting them and determining what the mean opinion score is, but we should WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
collecting them and determining what the mean opinion score is, but we should
know that it ranges from 0 to 5 and it reflects these 3 specific metrics.