24 Chapter 1: Quality of Service: An Overview
RFC 2598, “An Expedited Forwarding PHB”
RFC 2598 defines “An Expedited Forwarding PHB” and states the following:
The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service
through DS domains.
This means that when a network node receives a packet, it should be transmitted as soon as
possible (adding as little delay as possible). This sounds a lot like voice service, right?
Although RFC 2598 doesn’t explicitly discuss the intended use of this PHB, it can probably
be safely assumed that the primary intention for this PHB is real-time traffic, including voice
and, in some cases, interactive video. That’s not, of course, to say that this PHB isn’t ever used
for any other kind of traffic. I suppose that’s one of the great things about the DiffServ archi-
tecture implementation in Cisco equipment; it is very flexible and entirely user configurable.
When I teach QoS classes, my joke is that Cisco enables users to configure QoS any way they
want to … even if it’s wrong. RFC 2598 is actually one of the few things in the DiffServ archi-
tecture that provides an opportunity to get into real trouble with misconfiguration.
Consider the fact that the EF PHB’s main purpose is to provide a forwarding behavior that
introduces as little delay and jitter as possible. If more traffic is received for transmission
than an interface can transmit, a queue begins to form. When a device queues traffic, by
definition it introduces delay. As such, it can be inferred that building a queue is undesirable
when implementing the EF PHB.
Said another way, if a device queues traffic, it introduces delay; so to provide the EF PHB,
a device should not queue (or queue very little) traffic. Because this requirement means that
the EF traffic will be given strict priority for transmission (to minimize delay), there is a
risk that the receipt of too much EF traffic could cause starvation for other traffic on the link.
One might envision a situation in which there is a steady stream of EF traffic, received at
the line rate of the egress interface, and a stream of other traffic, received at the line rate of
the egress interface. In this situation, without a mechanism to prevent starvation, the strict
priority of the EF traffic on that link means that all the EF traffic is transmitted and none of
the other traffic is transmitted. That may very well be the intent of a particular user, but to prevent
this situation from unintentionally occurring, RFC 2598 calls for a measure of protection.
The measure that is called for to prevent the starvation of other traffic, just because a device
receives too much EF traffic, is the following provision:
The departure rate of the aggregate’s packets from any DiffServ node must equal or exceed a configurable rate.
This behavior can be represented by stating that the rate of arrival must be less than or equal
to the rate of departure, for packets receiving the EF PHB. To ensure that this is the case,
the RFC suggests that a policer be used to rate limit the EF traffic, which is what is used in
most Cisco devices. Specifically, if the configuration requires EF for all packets marked
DSCP 46, and if 128 kbps is the configured egress rate for traffic receiving the EF PHB, and
129 kbps of traffic marked DSCP 46 is offered, 1k of traffic marked DSCP 46 is dropped to
ensure that the rate of arrival into the EF queue does not exceed the rate of departure. This
example, by the way, assumes link congestion is present. When no congestion exists, queuing
does not become active and, therefore, the policing mechanism would also not become active.
Stated another way, when there is no congestion, there is no policing of traffic that would, in
the event of congestion, be placed in the priority queue for strict priority scheduling.