Now we know what the goal of Quality of Service is, and we'll find that we
actually have several different ways that we can accomplish that.
In fact, we've had different models throughout the years that have shown us
that we can do it one way, we can do it another way,
and in the modern network we'll find that there is one model that we've really
kind of seen embraced.
Now, there might be a situation where we consider a different model, but the
focus of this course and this exam is to really be looking at what we call the
diff-serve model.
But let's go and walk through these real quick. The first model we need to talk WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But let's go and walk through these real quick. The first model we need to talk
about, which is basically saying we don't have a model, is known as best effort
.
I know that if I'm going to sit down and play basketball, can you play
basketball sitting down?
If I'm going to go and get invited to play basketball, I'm going to give it my
best effort.
I definitely will always give it my best effort because I don't want to
disappoint my teammates. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Unfortunately, I'll probably still end up disappointing my teammates because I
'm not very good at basketball.
And so it'll just bounce off the rim or maybe even not even hit the rim either
way.
I am still giving it my best effort, which is great, but best effort does not
necessarily give us results.
The default behavior for our network switches is to present this concept of
best effort.
And so when we're looking at it from a QOS perspective, best effort is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so when we're looking at it from a QOS perspective, best effort is
basically saying this.
All apps are going to be treated the same.
So that's everything from my voice over IP to my bulk transfer of information
and data to my internet, web surfing, internet streaming traffic.
All of these will be treated the same. And as we can imagine, that's exactly
what we don't want to be doing on a network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because if I have to drop one of these packets because I've got a network
device here and we're getting so much traffic in that our buffers are
completely maxed out, they're full,
I'm going to have to start dropping frames. So what frames do I drop?
In a quality of service world, I would say, well, definitely drop the internet
and maybe drop the bulk file transfer type of packets.
But again, we're treating everybody the same here. And so it's called indiscrim
inate dropping of packets, meaning I'll drop anybody. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
inate dropping of packets, meaning I'll drop anybody.
It doesn't matter who I'm going to end up dropping. To me, all apps and all
network packets are the same.
And that's going to result in a very bad quality of experience for our voice
over IP users, while our bulk traffic and our internet users, they're not going
to even notice that they have any kind of issues on the link.
If the application can absorb that dropped packet for them. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If the application can absorb that dropped packet for them.
So we would like to talk about better model. And we have two different models
to talk about, the first of which is known as integrated services, otherwise
known as int serve.
It takes us back in time a little bit from a methodology perspective. When I
was first sitting down to learn about networking, I was learning about the
concept of circuit switched versus packet switched networks.
And there was a theory early on that our network should be based on circuits, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And there was a theory early on that our network should be based on circuits,
just like our phone lines at the time were built on circuits.
The idea here was that if I'm going to pick up the phone and talk to somebody,
and yes, this is me in like the 1990s talking to my friend with my long arms
and banana phone there I guess.
But either way, talking to my friend on the phone, we had a dedicated circuit,
meaning that there wasn't anything that anybody else had to do to try to get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
meaning that there wasn't anything that anybody else had to do to try to get
some of that bandwidth because they couldn't.
They couldn't get any of that bandwidth. This is a dedicated link between the
two. And as long as I was talking to my friend on this line, then that
bandwidth, if we want to call it that was completely reserved for us.
And once we hung up, then somebody else could use the circuit. And so this is
great other than it's also completely inefficient.
It's inefficient because for all we know, for all the come telecom company WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's inefficient because for all we know, for all the come telecom company
knows, my friend and I could both set our phones down and walk away and just
leave that hanging there.
And yeah, that again in the 90s that meant that we couldn't actually get
another phone call because they'd be busy and that was our only phone line, but
it was wasting the bandwidth.
And even if we didn't want to create this scenario where we could both set the
phones down, what about the time periods where we were maybe not talking to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
phones down, what about the time periods where we were maybe not talking to
each other?
Even just sitting here using words and talking to words, there's all these gaps
in the words and that's a bunch of bandwidth that's reserved for silence.
For really going to break this down and look at it from a millisecond
perspective, there's a whole lot of silence on the line that we are guaranteed
and dedicated to have.
But the natural upside here is that I don't need to worry about any lack of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But the natural upside here is that I don't need to worry about any lack of
quality on this connection.
So, InServe wants to replicate this and say that we're going to do this now for
quality of service.
To say that I've got a set of routers here and what I want to do is still
leverage the fact that this is a packet switch network, we're still in our TCP/
IP world.
And so we've got packets flowing among all of these routers, but if I wanted to
have a phone call from one end to the other, then I could still get a dedicated WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have a phone call from one end to the other, then I could still get a dedicated
reservation.
And we're talking about a reservation at this point, we're not talking about a
true circuit, but we're talking about creating sort of a virtual circuit
because it's a reservation of bandwidth.
So the idea here is now I'm going to reserve, let's just say I'm going to
reserve 100 kilobits per second from end to end. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
reserve 100 kilobits per second from end to end.
This requires an entire request set of, maybe a set of requests where I request
all the way down to the other side and then I get responses all the way back.
And this transaction was managed by a protocol known as RSVP.
And it really just stands for the resource reservation protocol, and yeah, it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it really just stands for the resource reservation protocol, and yeah, it
doesn't quite line up with RSVP, but as we maybe know from if we speak French
or otherwise in even American culture, we use this word RSVP to say that I want
to reserve my spot at a party or something along those lines.
So I can reserve something using an RSVP, which again going back to the French
stands for race bond a see who play, we're saying, please respond.
Ultimately RSVP as a protocol is going to manage these transactions for us and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Ultimately RSVP as a protocol is going to manage these transactions for us and
ideally reserve a dedicated set of bandwidth and end.
Now, in the same way that these circuit switch networks were inefficient, this
is not super efficient, because what if I don't actually need even half of that
100 kilobits per second reservation?
Well, it's dedicated, it's reserved, nobody else can have it.
And so there are upsides and downsides to both in serve and the alternative,
the diff serve model here that we're going to be talking about. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the diff serve model here that we're going to be talking about.
There's upsides and downsides to understand, and ultimately, in service sort of
seen as maybe having too many downsides.
So our upside, absolutely, it doesn't get better than having a true reservation
.
Even diff serve, our modern mechanisms can't do this.
But on the downside here, we're going to find that we have scaling issues. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And specifically what happens when we run out of resources, because we're
inefficient, we might find that we do run out of resources.
And so since we're out of resources, I guess we'll abbreviate it that way.
Once we're out of resources, this leads to RSVP rejections.
I can no longer get resources because all the resources have been reserved.
And I need to leave some amount of resources for non RSVP related traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I need to leave some amount of resources for non RSVP related traffic.
And so we see quite a few downsides to in serve, which is again, why we don't
typically see it deployed onto modern networks,
although it is still something that is supported and we could deploy.
So onto the model that we've been teasing, which is differentiated services,
otherwise known as diff serve.
diff serve embraces the packet switch nature of modern networking.
So there's no reservation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So there's no reservation.
We're not trying to replicate the concept of circuits.
We don't have these virtual circuits that we're trying to establish.
And instead, what we're going to do is we're going to rely on what we call per
pop behaviors.
Otherwise known as, if I can spell it, there we go, P H B's. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Otherwise known as, if I can spell it, there we go, P H B's.
So these per hot behaviors essentially break it down once again into a bunch of
devices that are communicating with each other.
But there is no end to end reservation.
And so when we're talking about reservations, we're really talking about end to
end because within serve, that's what we do.
We add this 100 kilobit per second reservation end to end from one side to the
other.
But instead, we're going to say there are no reservations from an end to end WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But instead, we're going to say there are no reservations from an end to end
perspective.
Instead, what we're going to do is we're going to rely on each one of these
devices as having the proper behavior.
But the problem, if we want to call it that, is that each one of these has its
own set of behaviors defined.
And so we need to make sure that we synchronize these behaviors via RQOS
configuration.
So just like in a packet switched world, and we think about our layer three WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So just like in a packet switched world, and we think about our layer three
routing, so often we bring a packet in and we look at the behavior that I have
defined.
And so I send it on hoping that the next device also has the proper behavior
defined.
And so that's exactly what the diff-serve model is built on, is saying that
each device is going to be responsible for executing the behavior that we
desire.
Importantly, in all of this, there are no guarantees. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
With in serve, we had guarantees.
That was the upside here.
We had a reservation guaranteed from end to end.
With diff-serve, we just don't have that.
Packets might make it three quarters of the way there and then end up getting
dropped.
That could absolutely happen in the diff-serve model.
Whereas with in serve, that shouldn't happen short of a packet being malformed
on transmission.
As long as we have the reservation, that bandwidth should be available and
there's really not going to be a way that it gets dropped due to a full buffer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But we might actually have buffer issues on the network that cause diff-serve
packets to get dropped.
Now, if we're not doing reservation, then how do we synchronize these behaviors
?
How do I know when a packet comes in that it's voice over IP?
Well, the way we do that is with a tag.
And these tags can be rather famous or maybe infamous among network engineers.
It's tags such as class of service, DSCP, the differentiated services code WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's tags such as class of service, DSCP, the differentiated services code
point.
As fancy as that sounds, you might notice differentiated services,
differentiated services.
So clearly the concepts are tied together.
There's also a more legacy IP precedence that we'll cover, but we pretty much
don't use that anymore.
It's always class of service or DSCP being layer two and layer three tags
respectively.
So the biggest upside that we see to diff-serve is just how efficient it is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We don't have to worry about accidentally reserving too much bandwidth because
if we do put too much of a bandwidth prioritization on, let's say our voice
over IP,
well, if we're not using that, then it'll get used by other traffic flows.
We don't have to stress about maybe running out of bandwidth that we can
reserve, which is a big problem down here with RSVP and the Inserve model.
So it's highly, highly efficient.
One of the biggest downsides to quality of service, that again is probably WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
One of the biggest downsides to quality of service, that again is probably
famous or infamous among network engineers,
is that it is extremely complex at times.
We have a bunch of different mechanisms that we're going to be learning and
covering.
We also have to worry about the fact that switches and routers handle quality
of service,
queuing and prioritization different from one another.
And so unfortunately it does create a little bit more for us to have to learn.
But when we compare that to the downsides of the Inserve model, by far diff-ser WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But when we compare that to the downsides of the Inserve model, by far diff-ser
ve is the superior way to do things,
again embracing that packet-switched implementation that networking has been
built on for so long.
So as we move forward, we're going to leave Inserve behind and focus on our
diff-serve mechanisms
and see how we can take advantage of them to deliver, again, that positive
quality of experience for our mission critical applications.