in the last video we saw that traffic can be classified and marked
but there's not much point to that unless we use this information in some
useful way so we need to take action on our traffic
throughout this video we're going to see how we can use these markings
and the actions we can take for each traffic class
in the last video we were classifying traffic based on their requirements
and marking packets so we can share these classifications
when we classify traffic we're putting the traffic into classes
we have a few different classes available to use and
several drop probabilities within each class
that means that we don't have a class for each application rather the class
groups applications by similar traffic requirements
packets are normally classified as they enter a router
if the packet already has markings this makes classification easier
if there's no marking or if the router chooses to ignore the markings
the packet may still be classified based on things like
source or destination ip address port protocol
that sort of thing if the router wants to mark the packet
this would typically be done after classification but before the packet is
sent out remember that quality of service is
locally significant meaning that each router or switch needs
to make its own decisions on how a packet is handled this is
called per-hop behavior or phb
once the classification is complete the next step is
queuing each interface will have several queues
these are usually implemented in hardware but there could be software
queues as well some routers or switches may have four
queues per interface others may have eight we're showing four
to keep it simple when packets are ready to be sent out
they are added to one of these queues based on its classification when the
interface is available the packet is moved from the queue and
is sent out the interface there will be many packets coming into a
router but a single interface can only put one packet on the wire at a time
so when there are multiple packets spread among different queues, how does the
router decide which packet to send next? this is handled by a component called
the scheduler the scheduler looks at the priority of
each queue and will decide which queue to service next
and that gets to the heart of how qos prioritizes traffic
the scheduler will service a high priority queue more often than it will
service a low priority queue. the question is can we adjust the amount
of priority a scheduler gives to each queue of
course we can consider this example which would suit a
four class model very well this allocates a third of the
interface's bandwidth to real-time traffic
best effort gets a quarter and scavenger gets only five percent
why does the best effort class get so much bandwidth
because it's the default class meaning a lot of traffic will end up here
now hang on is that a typo why is there nothing listed
next to the critical class well i'm glad you asked
the percentages shown here are limits that means
in times of congestion these queues will not be allowed any more than the
limits shown here the critical class is not given a
specific limit so you might assume that it has the
remaining 37 percent but that's not true imagine your link is
congested and real-time traffic is using five
percent of the link even though it's allowed to use more the
critical class can now make use of these unallocated resources
so that means that it can take advantage of these resources
before the other classes do if we set a limit on this class
that simply wouldn't happen if you're moving to a more complicated model
you can divide your categories up like in this example
this is just the same as the last example but it's divided up further
keep in mind these are just examples and you can tune these as needed
so you might have noticed that it's common for an interface to have eight
queues, which is great because that lines up really well with our eight classes
so when does the drop probability come into it
you'll remember from the last video that this is a bit like a subclass
within a class let's think about queues again
imagine a lot of one type of traffic arrives at the router
these packets are classified and added to a queue
if the ingress interface is much faster than the egress interface
these packets might even fill the entire queue
if a queue is full and more packets come in what's going to happen
without any special handling this packet will get dropped
and this is called a tail drop as is dropped from the tail of the queue
now this is where drop probability comes in drop probability can be set to
low medium or high when the queue fills up
the packets with the high drop probability are dropped first
which makes room in the queue. If there are no high probability packets medium
probability packets are dropped in this way we can still prioritize one
type of traffic over another within a single queue
so far we've been talking about using qos when the link is congested
that is when a link is full using qos to decide which traffic is forwarded
and which traffic is dropped that's great of course
but there are other qos tools available to us the first is policing
also known as rate limiting this is where we define a limit on how much
bandwidth certain traffic can have this could be a
type of traffic like ftp downloads traffic between two
particular ip addresses or some other combination
of conditions first think about the traffic we've
identified as shown here is common for traffic to
increase and decrease over time this is shown by the
high peaks in the graph when we configure policing we're setting
a hard limit that is a limit to the amount of
bandwidth that this traffic can have as shown by this line any amount of
traffic under this limit is said to be conforming anything above this limit is
said to be non-conforming the whole point of the
policer is to take action on any non-conforming packets
the simplest and probably most common action is to drop all non-conforming
packets this strictly enforces the rate limit
and would change our traffic pattern to look more like this
another option is to re-mark non-conforming packets rather than
dropping them maybe we could raise the drop
probability or move them into an entirely different class
this might be useful if we'd rather an upstream device decide which packets are
dropped and which are forwarded now here's where things might get a
little confusing a policer can recognize a small and
short burst in traffic that goes over the limit
in a case like this the policer will not consider this burst to be
non-conforming and will not take any additional action
however a large increase of traffic or traffic that is over the limit for an
extended duration is not considered a burst and therefore
is still non-conforming the point of this is that the policer
can be a bit friendly and won't penalize your traffic for
small infractions some traffic types do not respond well
to drops reclassifying can also be tricky as
packets may be sent out of order which can be very bad for certain types
of traffic the main point i'm trying to make here
is that you should understand the effect of policing on your traffic
before you apply it. Policing is not the only rate-limiting technology
we also have shaping this is very similar to policing
but it's a bit gentler we're still looking at traffic that goes over a
particular limit but we don't simply drop or remark the
traffic instead when traffic goes over the limit
excess packets are queued you could also call this buffering this
is where excess packets are stored in the queue
until there's bandwidth available to send them and this works really well
when dealing with small bursts of traffic
instead of just cutting these peaks off we're really smoothing them out
we're changing the shape of this graph we're smoothing out bursty traffic
now for the warnings if your traffic bursts are too large
your queue will fill up when the queue is full
no new packets can be accepted and tail drops will occur
also once again not all traffic likes shaping
shaping delays packets this is generally not good for things like real-time
traffic that really need a consistent and
regular delivery of packets now you might be wondering can we use
policing and shaping together absolutely you can consider a link
between a service provider and a customer
the ports on the routers may be capable of one gig
however the customer may only be paying for a 100 meg service
so that's all the provider will guarantee
the provider will then use a policer to rate limit the traffic on their port
to 100 meg anything over that will be dropped
now a policer... It's not ideal for a customer is it? The customer's interface
is capable of one gig so their router may try to send traffic
out at a rate higher than 100 meg a lot of this traffic will be dropped by
the provider which as we've said is not good for a lot of traffic types
so the customer could configure a 100 meg shaper on their interface
this will prevent outbound traffic from going over 100 meg
while buffering packets as needed this will prevent the provider's policer
from kicking in and dropping packets
let's take a step back and look at congestion again
we've already looked at how we can manage congestion when it occurs but
is there anything we can do to prevent it
well we can't prevent congestion entirely but there are a few things we
can do to help alleviate it we do this with RED and WRED
you do need a bit of tcp background to understand how RED and
WRED work in particular we're interested in acknowledgments and windowing
when data is sent using tcp the receiver will send back an acknowledgement
this is to confirm that the data has been received
if the acknowledgement is not received the original sender assumes the data was
lost and will resend it
it's not efficient to send an acknowledgement for every single packet
so tcp uses windowing the sender and receiver agree on a window size which
is the amount of data that can be sent before an acknowledgement is required
the receiver then sends a single acknowledgement to cover
all of this data the sender will pause and wait for the acknowledgement before
sending more data if the acknowledgement is not received
all the data in that window needs to be resent
now quite often the window size will start small
as acknowledgments are received both parties become more confident in the
stability of this connection and they will start to grow the window
size if acknowledgements go missing and data
needs to be resent then the window size will start to
shrink this is to minimize the amount of data that needs to be resent
over an unreliable connection the key point
is that the smaller the window the more acknowledgements need to be sent
this means the sender spends more time waiting and less time sending
i think that's enough tcp theory for now let's see how RED
fits into the picture when a link becomes congested
the buffer begins to fill up if the buffer is completely full
we will start seeing tail drops so what RED will do is it will randomly
select a few packets to be dropped yeah really
red will drop a few packets before the network gets congested
in order to help prevent congestion that sounds crazy
how does that even help well what this does
is it prevents the receiver from getting a packet which means they won't send an
acknowledgement a lost acknowledgement means the window
size will shrink the smaller window size means that
acknowledgements will need to be sent more often
in turn that means the sender will need to pause and wait for acknowledgements
more often the result is that the sender will not
send traffic as quickly which means less congestion
now there are two key points with RED. Firstly RED is not dropping packets all
the time it only starts operating as the link
approaches congestion. Second, RED is completely random
it sees every packet as being equal so any packet
can be a target that might sound a bit aggressive
and you know what it is some traffic is more important than others
so we should be able to discriminate a little bit when we're selecting which
packets to drop for this reason we have Weighted RED
this uses class information to target lower priority flows more often than
higher priority flows keep in mind the high priority traffic
isn't completely immune it's just hit less often
so in practice we only ever use WRED not RED
and now for the warning we shouldn't use RED or WRED on
udp traffic why because it will probably do more harm
than good udp does not have acknowledgments or window sizes
so dropping udp traffic won't improve congestion
the sender won't slow down but we still have missing packets
and that brings us to the end of this introduction to qos
of course there's a lot more to learn but this solid foundation should make it
easier for you to take it from here i hope you've enjoyed this series please
let me know what you think