A rule in networking is that applications were not all created equal.
We don't have this sense in our modern networks nor should we.
Because if we think about the network facilitating all kinds of communications,
we have users
trying to do their work, they're trying to communicate to servers, but we also
have phones
out here and so users are trying to have phone calls with one another.
Meanwhile, we have somebody on their phone over here trying to stream maybe WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Meanwhile, we have somebody on their phone over here trying to stream maybe
some kind
of movie from the internet.
And then we've got users who are trying to maybe send major large files across
the network.
We see we have all kinds of applications.
And so we do see some number of important, maybe we'd call them critical types
of applications,
but those even come in different forms.
For example, we've got time sensitive applications, meaning we care how long it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
For example, we've got time sensitive applications, meaning we care how long it
takes for the
packets to make it across the network.
So we think about voice and video here being usually two of the primary drivers
for quality
of service conversations.
So we have these two users who are trying to have a phone call with one another
.
If the voice on the line is delayed by even 500 milliseconds, well, that's a
major problem.
Meanwhile, we know that this internet communication here where I'm just
streaming some kind of
video, if there's a 500 millisecond delay on this communication versus a 500 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
video, if there's a 500 millisecond delay on this communication versus a 500
millisecond
delay on this communication, we know that there's going to be major problems
with the
phone call and absolutely no problems.
In fact, probably not even noticed on the internet stream, thanks to buffering
and just
the nature of transferring large data.
In fact, even this situation where this user is transferring a large file to a
server somewhere
on the network, if it takes 500 milliseconds longer for it to show up, then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on the network, if it takes 500 milliseconds longer for it to show up, then
again, we might
not even notice unless we're doing a lot of smaller transactions, maybe that
starts to
add up over time.
But in these cases, we see that one of these types of applications is highly
time sensitive.
The phone calls have to get there in a certain amount of time.
And furthermore, the reliability matters because we do need these services to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And furthermore, the reliability matters because we do need these services to
be working.
That phone call does have to go through because it might be an emergency phone
call.
It might be a medical situation and we're trying to dial out to emergency
services.
And so not only is it time sensitive, but it is from a reliability perspective,
very
important.
Another way of saying this is this type of traffic must be prioritized over all
of the
other traffic types.
Now we can have some other critical services as well that are not time WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now we can have some other critical services as well that are not time
sensitive, meaning
that maybe we've got business applications that have to happen, but they don't
necessarily
have to happen as fast as possible.
So we think about maybe inside of the data center space here.
Maybe I have another server over here and I want to do some kind of live
migration between
the two.
This involves virtual machines.
It's a pretty common application inside the data center. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's a pretty common application inside the data center.
It involves moving server services from one physical box to another.
Now the good news about this is while it's transferring, it remains online.
So I'm still receiving this file, I'm still servicing all of these different
stations
and users throughout the network while my data is also migrating on the back
end.
So is this a critical service?
Absolutely.
This is a mission critical service inside of the data center.
But is it time sensitive? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But is it time sensitive?
No, it's not time sensitive.
If it takes 500 milliseconds longer, then nobody's going to notice because
again we're
online while this is happening.
If we were offline while it's happening, it's a different conversation.
And so we're going to say that, yeah, that's a critical service.
And so what we'd like to do is still have some amount of reservation around the
resources
involved.
And when we're talking about resources on the network, we are typically talking
about
bandwidth. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
bandwidth.
For example, if I have to transfer a bunch of data and I say, okay, well, I'm
going to
reserve 100 megabits per second versus maybe I could reserve 500 megabits per
second on
a larger connection, well, then that transfer is going to take five times
longer on the
smaller link reservation.
And so we would still want to again, look at these critical services and say,
we need
to make sure that we're reserving resources so it can still happen as quickly WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to make sure that we're reserving resources so it can still happen as quickly
as possible.
But as far as the individual granular 500 millisecond type of latency, no, that
's not
really a concern of ours from a time sensitivity perspective.
And then naturally, we also have non critical services on the network.
And yeah, we can look at entertainment.
That's always going to be something that we're going to list.
If our organization allows for things like YouTube and Netflix to be watched WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If our organization allows for things like YouTube and Netflix to be watched
maybe during
launches and breaks or for that matter, maybe we need YouTube and Netflix to
perform our
jobs for one reason or another.
Either way, we'd probably still call that non critical.
For the most part, we don't typically need to reserve bandwidth and try to
prioritize
that traffic.
But we also have some other types of services that we might think about such as
email.
Email is work related for sure. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Email is work related for sure.
I mean, these workers over here might be sending their emails back and forth.
If I can draw an envelope here, how about that?
So we can send our emails back and forth.
But again, from a time sensitive perspective, it's not necessary that things
get there 500
millisecond sooner.
And neither do we really need to worry about reserving bandwidth for emails
because they
will eventually go through.
And so when the user expectation is that this application just takes time, it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so when the user expectation is that this application just takes time, it's
a very slow
communications mechanism.
Well, then we typically don't need to worry too much about those services from
a prioritization
perspective.
So as we see, we start to establish an order of priority here from the most
critical time
sensitive services to critical, not time sensitive services and down to non
critical traffic
that as long as it goes through eventually, then we're all good.
But I think it is worth noting that we do actually want these critical services WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But I think it is worth noting that we do actually want these critical services
or noncritical
services, these still need to be serviced.
If my emails aren't going through, if my file transfers, maybe that's another
one we
could put on here, if my file transfers aren't working and they take hours for
me to send
even a small file, well, that's, it's not a mission critical service.
It's not super time sensitive.
And yet it still does need to go through even just something as basic as being WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And yet it still does need to go through even just something as basic as being
able to use
the internet and go to our websites.
These days we have all kinds of mission critical services that are out there
that we still
need to be communicating with, even if we're not going to prioritize that
traffic.
Now a lot of this is going to come down to two concepts.
We care about the prioritization of traffic.
As we've said, we want to make sure that certain traffic types get favored over WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
As we've said, we want to make sure that certain traffic types get favored over
others.
But another conversation is going to have to do with what we said here with
bandwidth
that we need to consider the reservation of resources and specifically the
reservation
of our bandwidth.
So it's an interesting aspect to talk about bandwidth reservation because when
quality
of service was first becoming a big deal, we were talking about having WAN
circuits like
T1s and E1s that were about one and a half megabits per second. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
T1s and E1s that were about one and a half megabits per second.
And we have phones on both sides of these, which are we're trying to make phone
calls
across T1s.
We even had smaller ISDN lines, even the kilobits per second range.
And so when we're looking at these very, very small amounts of bandwidth on
these links,
well bandwidth reservation was kind of a big deal because I need to make sure
that there's
enough bandwidth for this phone conversation to happen. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
enough bandwidth for this phone conversation to happen.
Now if only the phone conversation was happening, this would be plenty of
bandwidth.
But naturally we've got other users connecting in and trying to send traffic
across this
link as well, and so if somebody is trying to send a file back and forth, that
could
easily consume all one and a half megabits per second.
So having that ability to reserve bandwidth and prioritize that traffic over
the rest,
that was very important with small bandwidth links. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that was very important with small bandwidth links.
But now when we think about the modern network, I might have a switch
connecting to another
switch and this could be a 10 gigabit per second link.
And if we're in the data center, we might even be talking about 100 or 400 and
yes,
even 800 gigabits per second between switches.
And so when we look at the amount of bandwidth saying like even if we just have
a gig, but
let alone something like 10 gigabits per second, is QOS still needed. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let alone something like 10 gigabits per second, is QOS still needed.
Because a voice call is extremely small and therefore it doesn't seem like it's
going
to be a necessity for us to have to deploy quality of service when we have
these very
large network pipes.
Well as you might imagine, we're all here to talk about quality of service and
so the
answer is an emphatic yes.
But why is it still important?
Why do we still need it when we're not necessarily talking about these very WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Why do we still need it when we're not necessarily talking about these very
small bandwidth types
of pipes?
Well there are probably a lot of different reasons for that but I'll go ahead
and focus
on a couple of them.
First of all, every pipe, every link, whether it's a very small pipe or a 10
gig or a 100
gig link between devices, they all have the potential to be full.
And so if they are filled up because somebody is just consuming all of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so if they are filled up because somebody is just consuming all of the
throughput, then
even in these situations where we have so much bandwidth available, if we're
full, then
we start dropping packets.
And so which packets are we going to drop?
Well that's a good question and it depends on how we set up our quality of
service.
We probably hope that we're going to keep our voice calls online and not drop
those
packets but we can see that even if a 10 gig connection exists between switches
, that there
might be a situation where the buffers fill up, the bandwidth is peaked out, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
might be a situation where the buffers fill up, the bandwidth is peaked out,
and we do
need to worry about those voice packets still making it through.
And the other aspect of this, so this has to do with our resource reservations,
but the
other aspect to this is the concept of that prioritization that we talked about
and specifically
the order of transmissions.
Because I might have this very small voice packet, this might be under 100 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because I might have this very small voice packet, this might be under 100
bytes typically.
And so it's very small and it just needs to get sent out very quickly.
Say okay that's great, except by the time it shows up, it has these monster
packets that
need to be transmitted first.
And each one of these are the ethernet maximum of 1500 bytes that are going to
take some
amount of time in order to send out the interface.
And so this is no different than us showing up in line at an amusement park and
having
to wait behind people who are in front of us. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to wait behind people who are in front of us.
Now in that case we're probably all the same size I would think.
But either way we say okay well this packet has to wait its turn.
Is that really what we want to have happen on our switches?
Do we want this critical voice packet to have to wait its turn?
Yeah, from a seconds perspective, it doesn't take that long to send a packet.
But what if there's 10 of these in a row?
And what if it does add 50 milliseconds of wait time, as humans we typically
don't worry WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
don't worry
too much about 50 milliseconds until again we're on a phone call and now all of
a sudden
we have a delay when we're trying to communicate with one another.
And furthermore the further back in the queue that we are the more likely a
packet is to
get dropped in the situation where it's full.
So these are reasons why quality of service continues to matter even on modern
networks
where we have these massive bandwidth types of pipes.
It's all about making sure that we address the level of criticality of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's all about making sure that we address the level of criticality of the
different
traffic types in our network and from an end to end perspective we want to make
sure
that we are giving the prioritization and the reservation of resources
necessary to
ensure a very high quality of experience on those critical apps.
[BLANK_AUDIO]