|
0:00:14
|
The next QoS tool that we can apply to the hierarchical
|
|
0:00:18
|
queuing framework is the weighted random early detection or the
|
|
0:00:24
|
WRED feature.
|
|
0:00:27
|
Now random early detection is technically not a queuing mechanism
|
|
0:00:32
|
and it's the difference between the congestion management techniques
|
|
0:00:35
|
versus the congestion avoidance techniques
|
|
0:00:40
|
where the previous two that we looked at: the weighted fair queuing
|
|
0:00:44
|
and the bandwidth reservation and the low latency queuing
|
|
0:00:48
|
with prioritization, both of those are considered congestion
|
|
0:00:51
|
management techniques because they don't really
|
|
0:00:54
|
come into effect until there is other traffic that is taking
|
|
0:00:57
|
up the space in the output queue.
|
|
0:01:01
|
So again, with the bandwidth keyword it doesn't make sense
|
|
0:01:04
|
to do a reservation if there's no other traffic that's actually
|
|
0:01:07
|
using the interface.
|
|
0:01:09
|
It's only an issue when multiple classes are contending for the
|
|
0:01:13
|
same bandwidth and we need to drop one in favor of the other.
|
|
0:01:17
|
That's what essentially we're doing with the bandwidth reservation.
|
|
0:01:22
|
Now in random early detection or weighted random early detection
|
|
0:01:26
|
the idea is that we are to drop packets out of the output
|
|
0:01:30
|
queue or deny them admission in the output queue before the
|
|
0:01:34
|
queue is completely full.
|
|
0:01:38
|
So this is an alternative to the tail drop that we talked about
|
|
0:01:40
|
before where with first in first out and weighted fair queuing
|
|
0:01:47
|
that as packets enter the tail of the queue
|
|
0:01:50
|
and wait to get admitted to the head of the queue
|
|
0:01:54
|
if the output queue gets to its maximum value
|
|
0:01:57
|
then any new packets that try to be admitted are going to have to be dropped.
|
|
0:02:02
|
And since they're dropped as they're trying to come in
|
|
0:02:04
|
the back end of the queue which is the tail, we are
|
|
0:02:07
|
considering this tail drop.
|
|
0:02:09
|
Now the reason that this becomes an issue
|
|
0:02:12
|
is that the application's conversation can't be split up
|
|
0:02:17
|
into multiple packets that are being queued.
|
|
0:02:20
|
And specifically this is a problem with TCP based applications.
|
|
0:02:27
|
So let's say theoretically that we have the output queue
|
|
0:02:31
|
that is waiting to admit traffic onto the transmit ring.
|
|
0:02:36
|
And the output queue size is a 100
|
|
0:02:41
|
So we have three different packets that try to get admitted.
|
|
0:02:46
|
We'll say that these are 3, 2 and 1
|
|
0:02:49
|
and each of these are 40 long.
|
|
0:02:54
|
Now it doesn't really matter what the units are whether this is
|
|
0:02:56
|
bits or bytes or typically the queue limited is going to be
|
|
0:03:00
|
in packet numbers like just how many packets total can be
|
|
0:03:05
|
admitted to the queue, but let's assume that it's going to be
|
|
0:03:08
|
in bytes, so the output queue size maximum is a 100 bytes
|
|
0:03:13
|
each of these three packets are 40 bytes long each.
|
|
0:03:17
|
Now what this means is that the first packet
|
|
0:03:22
|
is going to be admitted
|
|
0:03:24
|
so then there's 60 bytes left over, so 40 are being used.
|
|
0:03:29
|
The second packet is admitted
|
|
0:03:32
|
there's an additional 40 used, so now there's 20 left over
|
|
0:03:36
|
When the third packet goes to get admitted, there's not
|
|
0:03:40
|
enough space in the output queue, so it needs to be
|
|
0:03:42
|
discarded.
|
|
0:03:44
|
Again, this occurs at the tail of the queue
|
|
0:03:49
|
which would then make this a tail drop.
|
|
0:03:52
|
So the first two packets one and two, they get admitted
|
|
0:03:55
|
third packet doesn't. The problem becomes if packets 1, 2 and 3
|
|
0:04:00
|
are part of the same TCP segment. When the
|
|
0:04:06
|
source is sending packets to the destination
|
|
0:04:12
|
if the destination is expecting three segments and it only
|
|
0:04:16
|
gets two of them, generally
|
|
0:04:20
|
it is not going to acknowledge the source.
|
|
0:04:23
|
Now it's going to depend on other optimizations of the
|
|
0:04:26
|
TCP application itself like TCP selective acknowledgements
|
|
0:04:30
|
but in the vast majority of cases, if the TCP window
|
|
0:04:35
|
size, so basically the segments that I'm sending and then waiting for
|
|
0:04:40
|
an acknowledgment back if some of the segments are
|
|
0:04:43
|
received, but not all of them, it means that the destination
|
|
0:04:48
|
will not send an acknowledgement which means that the source would
|
|
0:04:52
|
need to do what, so if the source sends the packets out, but
|
|
0:04:55
|
doesn't get an acknowledgement, what does it assume?
|
|
0:04:58
|
It assumes that all the packets were lost and it needs to do a
|
|
0:05:02
|
retransmission.
|
|
0:05:04
|
Now the reason that this is a problem in this specific case
|
|
0:05:07
|
is that if the first two packets one and two
|
|
0:05:11
|
are admitted to the output queue and then get sent
|
|
0:05:14
|
but ultimately have to be retransmitted anyways
|
|
0:05:18
|
it means that they took space in the output queue
|
|
0:05:21
|
over some other packets that could potentially have been sent.
|
|
0:05:26
|
So we end up in an inefficient transmission because
|
|
0:05:29
|
a part of the conversation is dropped, you might as well have just
|
|
0:05:32
|
dropped the entire thing because it needs to be retransmitted
|
|
0:05:35
|
anyways and this is generally what random early detection is
|
|
0:05:40
|
designed to prevent.
|
|
0:05:42
|
So before packets are admitted to the output queue
|
|
0:05:46
|
it's going to look at what is the current queue depth
|
|
0:05:49
|
or essentially how long is the queue, how many packets are in there.
|
|
0:05:55
|
Based on the packet's weighting which could be determined
|
|
0:05:59
|
either by the IP precedence value, the DSCP value
|
|
0:06:04
|
or a manual class definition that we call the discard class
|
|
0:06:10
|
the router is going to calculate based on the length of the queue
|
|
0:06:14
|
and the mark probability for that individual class
|
|
0:06:18
|
should I either admit new packets of that type or should I drop
|
|
0:06:22
|
new packets of that type.
|
|
0:06:26
|
Now essentially what we see when we configure the default
|
|
0:06:28
|
values here is that the packets with a higher DSCP value or
|
|
0:06:33
|
a higher IP precedence value are less likely to be dropped
|
|
0:06:38
|
than packets with a lower priority value.
|
|
0:06:44
|
So not only is this going to prevent the tail drop
|
|
0:06:47
|
which means that we would have to retransmit any packets
|
|
0:06:51
|
that were sent, but not acknowledged
|
|
0:06:54
|
it also means that our higher priority traffic
|
|
0:06:58
|
so anything that is marked with DSCP EF or IP precedence 5
|
|
0:07:03
|
it means that those packets are going to be less likely to be
|
|
0:07:07
|
dropped than anything that is lower priority.
|
|
0:07:12
|
And again, as we talked about with the DSCP values
|
|
0:07:14
|
technically anything that is marked as AF which again, DSCP AF is
|
|
0:07:20
|
the assured forwarding any of those packets technically should
|
|
0:07:23
|
not be dropped at all.
|
|
0:07:26
|
They're guaranteed delivery because they're assured to be
|
|
0:07:28
|
forwarded throughout the network.
|
|
0:07:30
|
So when we look at the defaults for this,
|
|
0:07:32
|
if we simply were to either configure the random detect command on the
|
|
0:07:37
|
interface which would be the legacy version
|
|
0:07:40
|
or we were to configure it under the class with either
|
|
0:07:44
|
random detect, random detect DSCP based, random detect
|
|
0:07:48
|
discard class based that's going to determine what value
|
|
0:07:52
|
are we looking at to figure out what is the weighting of the packet.
|
|
0:07:58
|
So let's say here now on Router 4
|
|
0:08:05
|
Router 4's connection to BB3
|
|
0:08:08
|
we want to apply weighted random early detection
|
|
0:08:13
|
to this Ethernet segment.
|
|
0:08:15
|
So we'll say as packets go out the LAN interface
|
|
0:08:20
|
we're going to selectively drop packets that have
|
|
0:08:23
|
a lower precedence in favor of packets that have a
|
|
0:08:26
|
higher precedence.
|
|
0:08:29
|
Now we could do this on a per class basis
|
|
0:08:33
|
where we say maybe just the web traffic is going to use
|
|
0:08:35
|
random detection or not voice traffic is going to use
|
|
0:08:39
|
random detection
|
|
0:08:42
|
so just like the class based weighted fair queuing, we can
|
|
0:08:45
|
define the individual types of traffic that are going to be
|
|
0:08:48
|
applied to that or we could apply it just to class default.
|
|
0:08:57
|
So first on Router 4 let's apply it just to the default class
|
|
0:09:03
|
so I'll configure a policy map that we'll call WRED
|
|
0:09:08
|
and this is for class class-default
|
|
0:09:12
|
we want to apply random detection.
|
|
0:09:17
|
Now in most versions, the default here is going to be precedence based
|
|
0:09:23
|
which means it's only going to look at IP precedence values
|
|
0:09:26
|
0 through 7
|
|
0:09:28
|
where if we were to say it is DSCP based
|
|
0:09:31
|
it means that the queuing is going to be a little bit more
|
|
0:09:34
|
granular because there are more DSCP values than there are
|
|
0:09:39
|
IP precedence values
|
|
0:09:41
|
where DSCP is going to be values 0 through 63
|
|
0:09:43
|
and precedence is just values 0 through 7
|
|
0:09:49
|
Now once we apply this onto the link if we say
|
|
0:09:51
|
service policy output is WRED
|
|
0:09:56
|
then we look at the show policy map interface Fast Ethernet 0/0
|
|
0:10:04
|
it says that the...
|
|
0:10:18
|
And this one doesn't show it. Usually it says that's random detection
|
|
0:10:21
|
and...
|
|
0:10:24
|
what type it is doing. You'll see sometimes it's hard to read this
|
|
0:10:27
|
because the output is skewed a little bit, so let me
|
|
0:10:31
|
select this and let's look at this output here in
|
|
0:10:37
|
Notepad.
|
|
0:10:56
|
It says that there are seven different possible classes of
|
|
0:10:59
|
traffic which are 0 through -- or excuse me, eight possible classes
|
|
0:11:02
|
of traffic 0 through 7, this is referring to the IP precedence
|
|
0:11:06
|
values. It says how many bytes are being transmitted, how many
|
|
0:11:11
|
packets are randomly dropped versus tail drop.
|
|
0:11:15
|
Now there's three specific configuration values that we
|
|
0:11:19
|
care about for the random detection, actually technically four.
|
|
0:11:23
|
But the main three are going to be what is the minimum threshold
|
|
0:11:27
|
what is the maximum threshold and what is the mark probability.
|
|
0:11:32
|
When packets get to the minimum threshold where in this case it means
|
|
0:11:36
|
how many packets are in the output queue
|
|
0:11:38
|
so simply the number of packets, not the bytes.
|
|
0:11:41
|
It says that for precedence 0 if there are at least 20 packets
|
|
0:11:48
|
in the output queue, I'm going to start to randomly drop them.
|
|
0:11:53
|
Now the rate at which I drop them is going to be some
|
|
0:11:57
|
value that is less than one out of ten where when I start
|
|
0:12:06
|
at 20 and I climb towards 40 which is the maximum threshold
|
|
0:12:12
|
I'm going to approach dropping the packets every one out of ten
|
|
0:12:16
|
or 10 percent of them
|
|
0:12:20
|
so the key point being that the more packets are
|
|
0:12:22
|
in the queue, the more likely they are to be dropped.
|
|
0:12:27
|
So as we approach the maximum threshold, the number that are
|
|
0:12:32
|
being dropped approaches the mark probability
|
|
0:12:35
|
which in this case is one out of ten by default.
|
|
0:12:39
|
So if there are exactly 40 packets of precedence 0
|
|
0:12:43
|
it means that every one out of ten, we're going to be dropping.
|
|
0:12:47
|
If we exceed the maximum threshold, then tail drop is going to occur.
|
|
0:12:54
|
So normally tail drop doesn't happen until we exceed the maximum threshold.
|
|
0:13:00
|
The other configuration value is the exponential weighting constant.
|
|
0:13:06
|
This controls over how long do we sample the average of the queue length.
|
|
0:13:13
|
So the actual calculation for how the average is derived
|
|
0:13:19
|
is listed here. Again, this isn't really something that you need to
|
|
0:13:22
|
memorize for the exam. A lot of the mathematics behind the queuing
|
|
0:13:26
|
mechanisms really are not going to be significant to us.
|
|
0:13:30
|
They're only really an issue programmatically for how these were
|
|
0:13:33
|
implemented in the first place. From our perspective, we're
|
|
0:13:36
|
just simply inputting what the different arguments are
|
|
0:13:39
|
and then the feature is going to figure out this type of stuff on its own
|
|
0:13:42
|
behind the scenes.
|
|
0:13:47
|
But if we also look at the other possible options
|
|
0:13:51
|
it says that if the traffic is class number 7
|
|
0:13:56
|
which is IP precedence 7
|
|
0:13:58
|
notice that the minimum threshold is larger
|
|
0:14:02
|
than it is for precedence 0
|
|
0:14:06
|
so what this essentially means is that if we have an equal distribution
|
|
0:14:12
|
of precedence 0 through 7
|
|
0:14:14
|
it means that seven is less likely to be dropped than
|
|
0:14:18
|
zero because we don't actually start dropping packets until we get
|
|
0:14:22
|
to 34 in the output queue as opposed to starting at 20
|
|
0:14:31
|
Now if we were to look at this for some of the other options
|
|
0:14:33
|
if we were to say under policy map WRED for class
|
|
0:14:42
|
class-default I'll say we want to do random detection
|
|
0:14:46
|
but in this case do it with dscp
|
|
0:14:50
|
so we'll say no random detection precedence
|
|
0:14:57
|
or precedence-based
|
|
0:15:00
|
I want to do random detection dscp based
|
|
0:15:04
|
when we look at the show policy map output
|
|
0:15:17
|
the difference is going to be that this is now based on
|
|
0:15:21
|
the dscp values as opposed to the IP precedence.
|
|
0:15:25
|
Now we won't actually see all of these until there are
|
|
0:15:28
|
precedence values that are marked with that
|
|
0:15:31
|
so we can see from this output it says just dscp default
|
|
0:15:35
|
had two packets transmitted
|
|
0:15:38
|
the minimum threshold is 20 and the maximum threshold is 40
|
|
0:15:45
|
So to figure out exactly what the different values are
|
|
0:15:50
|
let's send different types of markings through Router 4's
|
|
0:15:54
|
queue, so specifically if we look at the diagram, this is
|
|
0:15:58
|
applied onto Fast Ethernet 0/0 of Router 4
|
|
0:16:01
|
so I want to send packets out to BB3, but I want to send it
|
|
0:16:07
|
with different marking values.
|
|
0:16:10
|
Now there's a couple of different ways that I can do this
|
|
0:16:13
|
and let's say we do it from Router 1
|
|
0:16:17
|
When Router 1 goes to reach any of the destinations that are
|
|
0:16:21
|
behind BB3
|
|
0:16:25
|
which specifically in this case are 31.3, 31.2, 31.0
|
|
0:16:31
|
and 31.1
|
|
0:16:35
|
so from Router 1 if I were to trace 31.0.0.1
|
|
0:16:40
|
this is one of the destinations that's attached to BB3
|
|
0:16:44
|
so if I ping 31.0.0.1
|
|
0:16:48
|
and send a high repeat count
|
|
0:16:50
|
we should see on Router 4 that these are now being
|
|
0:16:56
|
accounted by the class-default.
|
|
0:17:03
|
So notice which counter is going up. It's the one that is
|
|
0:17:06
|
for the DSCP default.
|
|
0:17:10
|
There was also dscp cs6
|
|
0:17:13
|
which if we were to look at an access list
|
|
0:17:17
|
let's say access list 100 permit ip any any with a precedence
|
|
0:17:22
|
of 6, this is internet
|
|
0:17:31
|
this basically means it's the router's control plane packets.
|
|
0:17:36
|
So internally, the router is marking its RIP updates
|
|
0:17:39
|
and its BGP updates as the higher precedence values
|
|
0:17:44
|
so it means these are going to be less likely to be dropped
|
|
0:17:47
|
as they're transmitted to the output queue.
|
|
0:17:53
|
Now when we talk about the control plane, this gets a little bit
|
|
0:17:56
|
more complex too because the router is going to treat its own
|
|
0:17:59
|
locally generated control plane packets differently
|
|
0:18:03
|
than anything that is transiting through the router
|
|
0:18:07
|
and there's a good document on Cisco's website that talks about
|
|
0:18:09
|
this. If you search for pak_priority pak priority
|
|
0:18:19
|
it's how routing updates and Layer 2 control packets are
|
|
0:18:23
|
queued on an interface with a QoS service policy.
|
|
0:18:29
|
So this marking that's called pak priority
|
|
0:18:33
|
this is an internal packet label inside the router assigned by
|
|
0:18:36
|
the interface driver that provides priority through the router itself.
|
|
0:18:43
|
So essentially this is a priority flag for the router's CPU.
|
|
0:18:47
|
So it means that your OSPF packet is going to be processed
|
|
0:18:50
|
before a normal regular IP transit packet.
|
|
0:18:54
|
Then you'll see it talks about some of the different control
|
|
0:18:58
|
plane protocols like let's look for BGP.
|
|
0:19:01
|
It says RIP and OSPF are marked with precedence 6 and
|
|
0:19:06
|
pak priority where BGP is marked with precedence 6, but
|
|
0:19:11
|
is not set to pak priority
|
|
0:19:15
|
then IOS must also ensure low drop probability for IS to IS
|
|
0:19:18
|
EIGRP, PPP and HDLC on POS interfaces
|
|
0:19:24
|
operation and maintenance and ARP for ATM.
|
|
0:19:29
|
So these are using the internal pak priority value in the packet buffer header.
|
|
0:19:32
|
Basically what this means is that without any configuration
|
|
0:19:38
|
the router's automatically going to prioritize its control plane packets.
|
|
0:19:41
|
So you don't necessarily need to match OSPF and match
|
|
0:19:45
|
RIP and put those in a priority queue.
|
|
0:19:48
|
Technically the router's going to do this internally automatically.
|
|
0:19:52
|
So unless the router is basically at a 100 percent load
|
|
0:19:55
|
then it's very likely that you're going to drop the control plane
|
|
0:19:58
|
based on a queuing problem.
|
|
0:20:03
|
But we can see this on Router 4 when we look at the show policy
|
|
0:20:06
|
map interface output
|
|
0:20:08
|
this is both the RIP packets and the BGP packets that are
|
|
0:20:12
|
being marked as CS6 which again are internet.
|
|
0:20:18
|
Normally for data traffic, you're not supposed to go over precedence 5
|
|
0:20:22
|
which is critical
|
|
0:20:24
|
and again, if we compare this to the dscp values
|
|
0:20:29
|
CS5 which is critical is 101110
|
|
0:20:34
|
this is backwards compatible with DSCP EF 101110
|
|
0:20:40
|
so if something is marked as EF
|
|
0:20:43
|
a device that's running only IP precedence
|
|
0:20:46
|
they're going to treat that as IP precedence 5
|
|
0:20:52
|
Ok, so let's go to Router 1 and let's try out some of these
|
|
0:20:56
|
different values.
|
|
0:20:57
|
So on Router 1 let's do an extended ping
|
|
0:20:59
|
we'll say to ping 31.0.0.1
|
|
0:21:05
|
I want extended commands
|
|
0:21:08
|
and I want to set the type of service.
|
|
0:21:12
|
So I would need to figure out what is the type of service
|
|
0:21:15
|
that matches to one of these DSCP values.
|
|
0:21:20
|
Let's say AF 41
|
|
0:21:24
|
which is 100010
|
|
0:21:28
|
then remember in the type of service, there's an additional
|
|
0:21:31
|
two leading bits or two trailing bits
|
|
0:21:35
|
so to the right
|
|
0:21:37
|
so if I were to say in binary 100010
|
|
0:21:42
|
then add the two additional trailing bits 00
|
|
0:21:49
|
then in hex this is 88
|
|
0:21:53
|
this then should be the type of service
|
|
0:22:01
|
and on Router 4 now if we look at the show policy map
|
|
0:22:06
|
interface serial 0/1/0
|
|
0:22:11
|
or actually Fast Ethernet 0/0
|
|
0:22:19
|
it says af 23
|
|
0:22:24
|
let's see how did it get af 23? Af 23 is...
|
|
0:22:32
|
010110
|
|
0:22:48
|
Actually I think it might be taking the -- that might be the type of
|
|
0:22:53
|
service in decimal then, not in hex. So let me try
|
|
0:22:58
|
this again. Let's ping 31.0.0.1
|
|
0:23:07
|
extended commands yes
|
|
0:23:10
|
The type of service so I want to say this in decimal let's say
|
|
0:23:15
|
136
|
|
0:23:19
|
then on Router 4 if we show policy map interface
|
|
0:23:25
|
that's 41, ok so the ping command that's taking the type of service
|
|
0:23:28
|
in decimal, not in hex
|
|
0:23:30
|
but you can use this to quickly test the different categorizations
|
|
0:23:34
|
the different markings without having to configure a full policy that says
|
|
0:23:39
|
set the traffic as it's going outbound
|
|
0:23:41
|
but if we look at the full output of this
|
|
0:23:45
|
and again, it's kind of hard to see the columns because the
|
|
0:23:48
|
font is skewed there, but if we look at the full output on Router 4
|
|
0:23:54
|
notice that when we compare AF 23 to AF 41
|
|
0:24:00
|
AF 41 has a higher minimum threshold and it's the same
|
|
0:24:08
|
as CS6
|
|
0:24:12
|
because again, if we look at these in binary
|
|
0:24:18
|
CS6 is 110000
|
|
0:24:25
|
where AF 41 is 110010
|
|
0:24:30
|
so it's the same first three bits 100
|
|
0:24:34
|
or actually no it's not, it was 110
|
|
0:24:39
|
so I have 41 versus CS6
|
|
0:24:44
|
so basically this just means they have the same minimum threshold values.
|
|
0:24:49
|
So you could selectively change this.
|
|
0:24:51
|
But what you would see is that by default, the higher
|
|
0:24:54
|
the marking, the less likely the traffic is going to be dropped.
|
|
0:25:03
|
So normally you wouldn't really need to play around with these
|
|
0:25:05
|
values. Within the scope of the lab exam, they would basically
|
|
0:25:08
|
have to tell you specifically change the minimum or maximum
|
|
0:25:12
|
threshold, the weighting constant or the mark probability
|
|
0:25:15
|
otherwise, you just simply need to turn the feature on.
|
|
0:25:19
|
Now another thing that this prevents is what is known
|
|
0:25:23
|
as global synchronization of TCP that is a problem
|
|
0:25:29
|
of the slow start feature of TCP which is for congestion management.
|
|
0:25:35
|
When multiple sending hosts go into the slow start feature
|
|
0:25:40
|
at the same time, it means that the queue utilization
|
|
0:25:46
|
is having very high periods of utilization followed by low
|
|
0:25:52
|
periods of utilization over and over and over so this kind of
|
|
0:25:56
|
saw tooth pattern
|
|
0:25:57
|
where these are the highs
|
|
0:26:02
|
and these are the lows
|
|
0:26:04
|
typically what this means is that when the traffic flow
|
|
0:26:08
|
gets to the high value, this is where a drop occurs.
|
|
0:26:14
|
When TCP figures out that a packet was lost by not hearing
|
|
0:26:18
|
an acknowledgement back in
|
|
0:26:21
|
it's not only going to perform retransmission, but it's going to do
|
|
0:26:24
|
what? It's going to drop its window size down.
|
|
0:26:30
|
Now the TCP window size controls how much traffic
|
|
0:26:33
|
can I send to the destination before I have to wait for an
|
|
0:26:37
|
acknowledgement back in.
|
|
0:26:40
|
So if my window size theoretically was one
|
|
0:26:43
|
it means that for every packet I send out, I have to wait
|
|
0:26:46
|
for an acknowledgement back in.
|
|
0:26:48
|
If the window size was 100, I could send a 100 packets
|
|
0:26:52
|
before waiting for an acknowledgement.
|
|
0:26:54
|
So the actual value is going to be negotiated between
|
|
0:26:57
|
the TCP client and the TCP server, but the key is that
|
|
0:27:01
|
when the drop occurs, if multiple hosts go into the
|
|
0:27:05
|
slow start state at the same time,
|
|
0:27:08
|
they eventually all drop their window size
|
|
0:27:12
|
to a low value
|
|
0:27:14
|
slowly start to build it up to a higher window size
|
|
0:27:18
|
where the drop occurs again
|
|
0:27:20
|
and then the process repeats itself over and over and over
|
|
0:27:23
|
where you have a number of source applications going to slow start
|
|
0:27:29
|
at the same time and the TCP sessions start to get synchronized
|
|
0:27:32
|
with each other.
|
|
0:27:34
|
Now random detection inherently prevents this
|
|
0:27:39
|
because the packets are randomly dropped out of the queue
|
|
0:27:42
|
as opposed to tail dropped all at the same time.
|
|
0:27:47
|
So the goal is that it selectively sends individual hosts into slow
|
|
0:27:51
|
start at different time indexes.
|
|
0:27:53
|
So again here, when we look at the thresholds
|
|
0:27:57
|
it says for the default DSCP which is zero
|
|
0:28:00
|
once there's 20 packets in the queue
|
|
0:28:02
|
I'm going to start randomly dropping them
|
|
0:28:06
|
at some value that is going to approach one out of ten
|
|
0:28:09
|
once I approach 40 packets in the queue.
|
|
0:28:14
|
But it doesn't necessarily mean that they're going to be all part
|
|
0:28:16
|
of the same flow, so I might drop one packet of one flow
|
|
0:28:21
|
and then a second packet of a different flow
|
|
0:28:25
|
If these are both TCP, the sender is not going to
|
|
0:28:29
|
get its acknowledgement back in which means that they are going to
|
|
0:28:31
|
go into slow start and they're going to do retransmission.
|
|
0:28:36
|
The problem though comes in with random detection
|
|
0:28:38
|
is that it's not going to help you for UDP traffic
|
|
0:28:40
|
because it's really relying on the congestion management
|
|
0:28:45
|
techniques of TCP itself
|
|
0:28:47
|
in order to adapt to the conditions of the network
|
|
0:28:50
|
because theoretically, if TCP was allowed to, it would always take
|
|
0:28:54
|
a 100 percent of every single link bandwidth in the network
|
|
0:28:59
|
because the window size is going to keep increasing
|
|
0:29:01
|
over and over and over so that the packets are
|
|
0:29:05
|
sent as many as possible before having to wait for an
|
|
0:29:09
|
acknowledgement back inbound.
|
|
0:29:11
|
So by selectively dropping individual packets, we're telling
|
|
0:29:14
|
one host at a time to go into slow start as opposed to
|
|
0:29:18
|
all of them at the same time.
|
|
0:29:20
|
Now the reason that this is important is that within
|
|
0:29:23
|
the scope of the lab exam, it's unlikely that they're going to
|
|
0:29:26
|
say configure weighted random early detection with this particular
|
|
0:29:30
|
mark probability denominator and this particular weighting factor.
|
|
0:29:35
|
It's more likely that they would give you some sort of problem
|
|
0:29:38
|
description that says maybe the applications are all getting
|
|
0:29:42
|
synchronized with their packet loss or there's too many
|
|
0:29:45
|
tail drops on the interface
|
|
0:29:48
|
that would be a good indication that random detection is used to
|
|
0:29:51
|
solve that because as opposed to tail drop, it is randomly dropping
|
|
0:29:56
|
the packets and it's preventing that global TCP synchronization
|
|
0:30:01
|
by sending individual hosts into slow start at separate intervals.
|
