draft-ietf-diffserv-phb-ef-02.txt   rfc2598.txt 
Internet Engineering Task Force Van Jacobson
Differentiated Services Working Group Kathleen Nichols
Internet Draft Cisco Systems
Expires August, 1999 Kedarnath Poduri
Bay Networks
February, 1999
An Expedited Forwarding PHB Network Working Group V. Jacobson
<draft-ietf-diffserv-phb-ef-02.txt> Request for Comments: 2598 K. Nichols
Category: Standards Track Cisco Systems
Status of this Memo K. Poduri
Bay Networks
This document is an Internet-Draft and is in full conformance June 1999
with all provisions of Section 10 of RFC2026.
This document is a product of the IETF Differentiated Services
Working Group. Comments are solicited and should be directed
to the working group mailing list.
Internet-Drafts are working documents of the Internet Engineering An Expedited Forwarding PHB
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Status of this Memo
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/1id-abstracts.txt Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
The definition of PHBs (per-hop forwarding behaviors) is a The definition of PHBs (per-hop forwarding behaviors) is a critical
critical part of the work of the Diffserv Working Group. This part of the work of the Diffserv Working Group. This document
document describes a PHB called Expedited Forwarding. We show the describes a PHB called Expedited Forwarding. We show the generality
generality of this PHB by noting that it can be produced by more of this PHB by noting that it can be produced by more than one
than one mechanism and give an example of its use to produce at mechanism and give an example of its use to produce at least one
least one service, a Virtual Leased Line. A recommended service, a Virtual Leased Line. A recommended codepoint for this PHB
codepoint for this PHB is given. is given.
A pdf version of this document is available at A pdf version of this document is available at
ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf
1. Introduction 1. Introduction
Network nodes that implement the differentiated services Network nodes that implement the differentiated services enhancements
enhancements to IP use a codepoint in the IP header to select a to IP use a codepoint in the IP header to select a per-hop behavior
per-hop behavior (PHB) as the specific forwarding treatment for (PHB) as the specific forwarding treatment for that packet [RFC2474,
that packet [RFC2474, RFC2475]. This draft describes a RFC2475]. This memo describes a particular PHB called expedited
particular PHB called expedited forwarding (EF). The EF PHB can forwarding (EF). The EF PHB can be used to build a low loss, low
be used to build a low loss, low latency, low jitter, assured latency, low jitter, assured bandwidth, end-to-end service through DS
bandwidth, end-to-end service through DS domains. Such a service domains. Such a service appears to the endpoints like a point-to-
appears to the endpoints like a point-to-point connection or a point connection or a "virtual leased line". This service has also
?virtual leased line?. This service has also been described as been described as Premium service [2BIT].
Premium service [2BIT].
Loss, latency and jitter are all due to the queues traffic Loss, latency and jitter are all due to the queues traffic
experiences while transiting the network. Therefore providing experiences while transiting the network. Therefore providing low
low loss, latency and jitter for some traffic aggregate means loss, latency and jitter for some traffic aggregate means ensuring
ensuring that the aggregate sees no (or very small) queues. that the aggregate sees no (or very small) queues. Queues arise when
Queues arise when (short-term) traffic arrival rate exceeds (short-term) traffic arrival rate exceeds departure rate at some
departure rate at some node. Thus a service that ensures no node. Thus a service that ensures no queues for some aggregate is
queues for some aggregate is equivalent to bounding rates such equivalent to bounding rates such that, at every transit node, the
that, at every transit node, the aggregate's maximum arrival rate aggregate's maximum arrival rate is less than that aggregate's
is less than that aggregate's minimum departure rate. minimum departure rate.
Creating such a service has two parts: Creating such a service has two parts:
1) Configuring nodes so that the aggregate has a well-defined 1) Configuring nodes so that the aggregate has a well-defined
minimum departure rate. (?Well-defined? means independent of the minimum departure rate. ("Well-defined" means independent of
dynamic state of the node. In particular, independent of the the dynamic state of the node. In particular, independent of
intensity of other traffic at the node.) the intensity of other traffic at the node.)
2) Conditioning the aggregate (via policing and shaping) so that its 2) Conditioning the aggregate (via policing and shaping) so that
arrival rate at any node is always less than that node's its arrival rate at any node is always less than that node's
configured minimum departure rate. configured minimum departure rate.
The EF PHB provides the first part of the service. The network The EF PHB provides the first part of the service. The network
boundary traffic conditioners described in [RFC2475] provide the boundary traffic conditioners described in [RFC2475] provide the
second part. second part.
The EF PHB is not a mandatory part of the Differentiated Services The EF PHB is not a mandatory part of the Differentiated Services
architecture, i.e., a node is not required to implement the EF architecture, i.e., a node is not required to implement the EF PHB in
PHB in order to be considered DS-compliant. However, when a DS- order to be considered DS-compliant. However, when a DS-compliant
compliant node claims to implement the EF PHB, the implementation node claims to implement the EF PHB, the implementation must conform
must conform to the specification given in this document. to the specification given in this document.
The next sections describe the EF PHB in detail and give examples The next sections describe the EF PHB in detail and give examples of
of how it might be implemented. The keywords ?MUST?, ?MUST NOT?, how it might be implemented. The keywords "MUST", "MUST NOT",
?REQUIRED?, ?SHOULD?, ?SHOULD NOT?, and ?MAY? that appear in this "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this
document are to be interpreted as described in [Bradner97]. document are to be interpreted as described in [Bradner97].
2. Description of EF per-hop behavior 2. Description of EF per-hop behavior
The EF PHB is defined as a forwarding treatment for a particular The EF PHB is defined as a forwarding treatment for a particular
diffserv aggregate where the departure rate of the aggregate's diffserv aggregate where the departure rate of the aggregate's
packets from any diffserv node must equal or exceed a packets from any diffserv node must equal or exceed a configurable
configurable rate. The EF traffic SHOULD receive this rate rate. The EF traffic SHOULD receive this rate independent of the
independent of the intensity of any other traffic attempting to intensity of any other traffic attempting to transit the node. It
transit the node. It SHOULD average at least the configured rate SHOULD average at least the configured rate when measured over any
when measured over any time interval equal to or longer than the time interval equal to or longer than the time it takes to send an
time it takes to send an output link MTU sized packet at the output link MTU sized packet at the configured rate. (Behavior at
configured rate. (Behavior at time scales shorter than a packet time scales shorter than a packet time at the configured rate is
time at the configured rate is deliberately not specified.) The deliberately not specified.) The configured minimum rate MUST be
configured minimum rate MUST be settable by a network settable by a network administrator (using whatever mechanism the
administrator (using whatever mechanism the node supports for node supports for non-volatile configuration).
non-volatile configuration).
If the EF PHB is implemented by a mechanism that allows unlimited If the EF PHB is implemented by a mechanism that allows unlimited
preemption of other traffic (e.g., a priority queue), the preemption of other traffic (e.g., a priority queue), the
implementation MUST include some means to limit the damage EF implementation MUST include some means to limit the damage EF traffic
traffic could inflict on other traffic (e.g., a token bucket rate could inflict on other traffic (e.g., a token bucket rate limiter).
limiter). Traffic that exceeds this limit MUST be discarded. This Traffic that exceeds this limit MUST be discarded. This maximum EF
maximum EF rate, and burst size if appropriate, MUST be settable rate, and burst size if appropriate, MUST be settable by a network
by a network administrator (using whatever mechanism the node administrator (using whatever mechanism the node supports for non-
supports for non-volatile configuration). The minimum and maximum volatile configuration). The minimum and maximum rates may be the
rates may be the same and configured by a single parameter. same and configured by a single parameter.
The Appendix describes how this PHB can be used to construct end- The Appendix describes how this PHB can be used to construct end-to-
to-end services. end services.
2.2 Example Mechanisms to Implement the EF PHB 2.2 Example Mechanisms to Implement the EF PHB
Several types of queue scheduling mechanisms may be employed to Several types of queue scheduling mechanisms may be employed to
deliver the forwarding behavior described in section 2.1 and thus deliver the forwarding behavior described in section 2.1 and thus
implement the EF PHB. A simple priority queue will give the implement the EF PHB. A simple priority queue will give the
appropriate behavior as long as there is no higher priority queue appropriate behavior as long as there is no higher priority queue
that could preempt the EF for more than a packet time at the that could preempt the EF for more than a packet time at the
configured rate. (This could be accomplished by having a rate configured rate. (This could be accomplished by having a rate
policer such as a token bucket associated with each priority policer such as a token bucket associated with each priority queue to
queue to bound how much the queue can starve other traffic.) bound how much the queue can starve other traffic.)
It's also possible to use a single queue in a group of queues It's also possible to use a single queue in a group of queues
serviced by a weighted round robin scheduler where the share of serviced by a weighted round robin scheduler where the share of the
the output bandwidth assigned to the EF queue is equal to the output bandwidth assigned to the EF queue is equal to the configured
configured rate. This could be implemented, for example, using rate. This could be implemented, for example, using one PHB of a
one PHB of a Class Selector Compliant set of PHBs [RFC2474]. Class Selector Compliant set of PHBs [RFC2474].
Another possible implementation is a CBQ [CBQ] scheduler that Another possible implementation is a CBQ [CBQ] scheduler that gives
gives the EF queue priority up to the configured rate. the EF queue priority up to the configured rate.
All of these mechanisms have the basic properties required for All of these mechanisms have the basic properties required for the EF
the EF PHB though different choices result in different ancillary PHB though different choices result in different ancillary behavior
behavior such as jitter seen by individual microflows. See such as jitter seen by individual microflows. See Appendix A.3 for
Appendix A.3 for simulations that quantify some of these differences. simulations that quantify some of these differences.
2.3 Recommended codepoint for this PHB 2.3 Recommended codepoint for this PHB
Codepoint 101110 is recommended for the EF PHB. Codepoint 101110 is recommended for the EF PHB.
2.4 Mutability 2.4 Mutability
Packets marked for EF PHB MAY be remarked at a DS domain boundary Packets marked for EF PHB MAY be remarked at a DS domain boundary
only to other codepoints that satisfy the EF PHB. Packets marked only to other codepoints that satisfy the EF PHB. Packets marked for
for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS
DS domain. domain.
2.5 Tunneling 2.5 Tunneling
When EF packets are tunneled, the tunneling packets must be When EF packets are tunneled, the tunneling packets must be marked as
marked as EF. EF.
2.6 Interaction with other PHBs 2.6 Interaction with other PHBs
Other PHBs and PHB groups may be deployed in the same DS node or Other PHBs and PHB groups may be deployed in the same DS node or
domain with the EF PHB as long as the requirement of section 2.1 domain with the EF PHB as long as the requirement of section 2.1 is
is met. met.
3. Security Considerations 3. Security Considerations
To protect itself against denial of service attacks, the edge of To protect itself against denial of service attacks, the edge of a DS
a DS domain MUST strictly police all EF marked packets to a rate domain MUST strictly police all EF marked packets to a rate
negotiated with the adjacent upstream domain. (This rate must be negotiated with the adjacent upstream domain. (This rate must be <=
<= the EF PHB configured rate.) Packets in excess of the the EF PHB configured rate.) Packets in excess of the negotiated
negotiated rate MUST be dropped. If two adjacent domains have rate MUST be dropped. If two adjacent domains have not negotiated an
not negotiated an EF rate, the downstream domain MUST use 0 as EF rate, the downstream domain MUST use 0 as the rate (i.e., drop all
the rate (i.e., drop all EF marked packets). EF marked packets).
Since the end-to-end premium service constructed from the EF PHB Since the end-to-end premium service constructed from the EF PHB
requires that the upstream domain police and shape EF marked requires that the upstream domain police and shape EF marked traffic
traffic to meet the rate negotiated with the downstream domain, to meet the rate negotiated with the downstream domain, the
the downstream domain's policer should never have to drop downstream domain's policer should never have to drop packets. Thus
packets. Thus these drops SHOULD be noted (e.g., via SNMP traps) these drops SHOULD be noted (e.g., via SNMP traps) as possible
as possible security violations or serious misconfiguration. security violations or serious misconfiguration. Similarly, since the
Similarly, since the aggregate EF traffic rate is constrained at aggregate EF traffic rate is constrained at every interior node, the
every interior node, the EF queue should never overflow so if it EF queue should never overflow so if it does the drops SHOULD be
does the drops SHOULD be noted as possible attacks or serious noted as possible attacks or serious misconfiguration.
misconfiguration.
4. References 4. IANA Considerations
[Bradner97] S. Bradner, ?Key words for use in RFCs to Indicate This document allocates one codepoint, 101110, in Pool 1 of the code
Requirement Levels?, Internet RFC 2119, March 1997. space defined by [RFC2474].
[RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, 5. References
?Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers?, Internet RFC 2474, December 1998.
[RFC2475] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and [Bradner97] Bradner, S., "Key words for use in RFCs to Indicate
W. Weiss, ?An Architecture for Differentiated Services?, Requirement Levels", BCP 14, RFC 2119, March 1997.
Internet RFC 2475, December 1998.
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, ?A Two-bit [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
Differentiated Services Architecture for the Internet?, Internet "Definition of the Differentiated Services Field (DS
Draft <draft-nichols-diff-svc-arch-00.txt>, November 1997, Field) in the IPv4 and IPv6 Headers", RFC 2474, December
ftp://ftp.ee.lbl.gov/papers/dsarch.pdf 1998.
[CBQ] S. Floyd and V. Jacobson, ?Link-sharing and Resource [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z.
Management Models for Packet Networks?, IEEE/ACM Transactions on and W. Weiss, "An Architecture for Differentiated
Networking, Vol. 3 no. 4, pp. 365-386, August 1995. Services", RFC 2475, December 1998.
[RFC2415] K. Poduri and K. Nichols, ?Simulation Studies of [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Increased Initial TCP Window Size?, Internet RFC 2415, Differentiated Services Architecture for the Internet",
September 1998. Work in Progress, ftp://ftp.ee.lbl.gov/papers/dsarch.pdf
[LCN] K. Nichols, ?Improving Network Simulation with [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource
Feedback?, Proceedings of LCN '98, October, 1998 Management Models for Packet Networks", IEEE/ACM
Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995.
5. Authors' Addresses [RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of
Increased Initial TCP Window Size", RFC 2415, September
1998.
Van Jacobson [LCN] K. Nichols, "Improving Network Simulation with Feedback",
Cisco Systems, Inc Proceedings of LCN '98, October 1998.
170 W. Tasman Drive
San Jose, CA 95134-1706
van@cisco.com
Kathleen Nichols 6. Authors' Addresses
Cisco Systems, Inc
170 W. Tasman Drive
San Jose, CA 95134-1706
kmn@cisco.com
Kedarnath Poduri Van Jacobson
Bay Networks, Inc. Cisco Systems, Inc
4401 Great America Parkway 170 W. Tasman Drive
Santa Clara, CA 95052-8185 San Jose, CA 95134-1706
kpoduri@baynetworks.com
EMail: van@cisco.com
Kathleen Nichols
Cisco Systems, Inc
170 W. Tasman Drive
San Jose, CA 95134-1706
EMail: kmn@cisco.com
Kedarnath Poduri
Bay Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
EMail: kpoduri@baynetworks.com
Appendix A: Example use of and experiences with the EF PHB Appendix A: Example use of and experiences with the EF PHB
A.1 Virtual Leased Line Service A.1 Virtual Leased Line Service
A VLL Service, also known as Premium service [2BIT], is A VLL Service, also known as Premium service [2BIT], is quantified by
quantified by a peak bandwidth. a peak bandwidth.
A.2 Experiences with its use in ESNET A.2 Experiences with its use in ESNET
A prototype of the VLL service has been deployed on DOE's ESNet A prototype of the VLL service has been deployed on DOE's ESNet
backbone. This uses weighted-round-robin queuing features of backbone. This uses weighted-round-robin queuing features of Cisco
Cisco 75xx series routers to implement the EF PHB. The early 75xx series routers to implement the EF PHB. The early tests have
tests have been very successful and work is in progress to make been very successful and work is in progress to make the service
the service available on a routine production basis (see available on a routine production basis (see
ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf and ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf and
ftp://ftp.ee.lbl.gov/talks/vj-i2qos-may98.pdf for details). ftp://ftp.ee.lbl.gov/talks/vj-i2qos-may98.pdf for details).
A.3 Simulation Results A.3 Simulation Results
A.3.1 Jitter variation A.3.1 Jitter variation
In section 2.2, we pointed out that a number of mechanisms might In section 2.2, we pointed out that a number of mechanisms might be
be used to implement the EF PHB. The simplest of these is a used to implement the EF PHB. The simplest of these is a priority
priority queue (PQ) where the arrival rate of the queue is queue (PQ) where the arrival rate of the queue is strictly less than
strictly less than its service rate. As jitter comes from the its service rate. As jitter comes from the queuing delay along the
queuing delay along the path, a feature of this implementation is path, a feature of this implementation is that EF-marked microflows
that EF-marked microflows will see very little jitter at their will see very little jitter at their subscribed rate since packets
subscribed rate since packets spend little time in queues. The EF spend little time in queues. The EF PHB does not have an explicit
PHB does not have an explicit jitter requirement but it is clear jitter requirement but it is clear from the definition that the
from the definition that the expected jitter in a packet stream expected jitter in a packet stream that uses a service based on the
that uses a service based on the EF PHB will be less with PQ than EF PHB will be less with PQ than with best-effort delivery. We used
with best-effort delivery. We used simulation to explore how simulation to explore how weighted round-robin (WRR) compares to PQ
weighted round-robin (WRR) compares to PQ in jitter. We chose in jitter. We chose these two since they"re the best and worst cases,
these two since they?re the best and worst cases, respectively, respectively, for jitter and we wanted to supply rough guidelines for
for jitter and we wanted to supply rough guidelines for EF EF implementers choosing to use WRR or similar mechanisms.
implementers choosing to use WRR or similar mechanisms.
Our simulation model is implemented in a modified ns-2 described Our simulation model is implemented in a modified ns-2 described in
in [RFC2415] and [LCN]. We used the CBQ modules included with ns- [RFC2415] and [LCN]. We used the CBQ modules included with ns-2 as a
2 as a basis to implement priority queuing and WRR. Our topology basis to implement priority queuing and WRR. Our topology has six
has six hops with decreasing bandwidth in the direction of a hops with decreasing bandwidth in the direction of a single 1.5 Mbps
single 1.5 Mbps bottleneck link (see figure 6). Sources produce bottleneck link (see figure 6). Sources produce EF-marked packets at
EF-marked packets at an average bit rate equal to their an average bit rate equal to their subscribed packet rate. Packets
subscribed packet rate. Packets are produced with a variation of are produced with a variation of +-10% from the interpacket spacing
+-10% from the interpacket spacing at the subscribed packet rate. at the subscribed packet rate. The individual source rates were
The individual source rates were picked aggregate to 30% of the picked aggregate to 30% of the bottleneck link or 450 Kbps. A mixture
bottleneck link or 450 Kbps. A mixture of FTPs and HTTPs is then of FTPs and HTTPs is then used to fill the link. Individual EF packet
used to fill the link. Individual EF packet sources produce sources produce either all 160 byte packets or all 1500 byte packets.
either all 160 byte packets or all 1500 byte packets. Though we
present the statistics of flows with one size of packet, all of
the experiments used a mixture of short and long packet EF
sources so the EF queues had a mix of both packet lengths.
We defined jitter as the absolute value of the difference between Though we present the statistics of flows with one size of packet,
the arrival times of two adjacent packets minus their departure all of the experiments used a mixture of short and long packet EF
times, |(aj-dj) - (ai-di)|. For the target flow of each sources so the EF queues had a mix of both packet lengths.
experiment, we record the median and 90th percentile values of
jitter (expressed as % of the subscribed EF rate) in a table. The
pdf version of this document contains graphs of the jitter
percentiles.
Our experiments compared the jitter of WRR and PQ implementations We defined jitter as the absolute value of the difference between the
of the EF PHB. We assessed the effect of different choices of WRR arrival times of two adjacent packets minus their departure times,
queue weight and number of queues on jitter. For WRR, we define |(aj-dj) - (ai-di)|. For the target flow of each experiment, we
the service-to-arrival rate ratio as the service rate of the EF record the median and 90th percentile values of jitter (expressed as
queue (or the queue?s minimum share of the output link) times the % of the subscribed EF rate) in a table. The pdf version of this
output link bandwidth divided by the peak arrival rate of EF- document contains graphs of the jitter percentiles.
marked packets at the queue. Results will not be stable if the
WRR weight is chosen to exactly balance arrival and departure
rates thus we used a minimum service-to-arrival ratio of 1.03. In
our simulations this means that the EF queue gets at least 31% of
the output links. In WRR simulations we kept the link full with
other traffic as described above, splitting the non-EF-marked
traffic among the non-EF queues. (It should be clear from the
experiment description that we are attempting to induce worst-
case jitter and do not expect these settings or traffic to
represent a ?normal? operating point.)
Our first set of experiments uses the minimal service-to-arrival Our experiments compared the jitter of WRR and PQ implementations of
ratio of 1.06 and we vary the number of individual microflows the EF PHB. We assessed the effect of different choices of WRR queue
composing the EF aggregate from 2 to 36. We compare these to a PQ weight and number of queues on jitter. For WRR, we define the
implementation with 24 flows. First, we examine a microflow at a service-to-arrival rate ratio as the service rate of the EF queue (or
subscribed rate of 56 Kbps sending 1500 byte packets, then one at the queue"s minimum share of the output link) times the output link
the same rate but sending 160 byte packets. Table 1 shows the bandwidth divided by the peak arrival rate of EF-marked packets at
50th and 90th percentile jitter in percent of a packet time at the the queue. Results will not be stable if the WRR weight is chosen to
subscribed rate. Figure 1 plots the 1500 byte flows and figure 2 exactly balance arrival and departure rates thus we used a minimum
the 160 byte flows. Note that a packet-time for a 1500 byte service-to-arrival ratio of 1.03. In our simulations this means that
packet at 56 Kbps is 214 ms, for a 160 byte packet 23 ms. The the EF queue gets at least 31% of the output links. In WRR
jitter for the large packets rarely exceeds half a subscribed simulations we kept the link full with other traffic as described
rate packet-time, though most jitters for the small packets are above, splitting the non-EF-marked traffic among the non-EF queues.
at least one subscribed rate packet-time. Keep in mind that the (It should be clear from the experiment description that we are
EF aggregate is a mixture of small and large packets in all cases attempting to induce worst-case jitter and do not expect these
so short packets can wait for long packets in the EF queue. PQ settings or traffic to represent a "normal" operating point.)
gives a very low jitter.
Table 1: Variation in jitter with number of EF flows: Our first set of experiments uses the minimal service-to-arrival
Service/arrival ratio of 1.06 and subscription rate of 56 Kbps ratio of 1.06 and we vary the number of individual microflows
(all values given as % of subscribed rate) composing the EF aggregate from 2 to 36. We compare these to a PQ
implementation with 24 flows. First, we examine a microflow at a
subscribed rate of 56 Kbps sending 1500 byte packets, then one at the
same rate but sending 160 byte packets. Table 1 shows the 50th and
90th percentile jitter in percent of a packet time at the subscribed
rate. Figure 1 plots the 1500 byte flows and figure 2 the 160 byte
flows. Note that a packet-time for a 1500 byte packet at 56 Kbps is
214 ms, for a 160 byte packet 23 ms. The jitter for the large packets
rarely exceeds half a subscribed rate packet-time, though most
jitters for the small packets are at least one subscribed rate
packet-time. Keep in mind that the EF aggregate is a mixture of small
and large packets in all cases so short packets can wait for long
packets in the EF queue. PQ gives a very low jitter.
1500 byte pack. 160 byte packet Table 1: Variation in jitter with number of EF flows: Service/arrival
# EF flows 50th % 90th % 50th % 90th % ratio of 1.06 and subscription rate of 56 Kbps (all values given as %
PQ (24) 1 5 17 43 of subscribed rate)
2 11 47 96 513 1500 byte pack. 160 byte packet
4 12 35 100 278 # EF flows 50th % 90th % 50th % 90th %
8 10 25 96 126 PQ (24) 1 5 17 43
24 18 47 96 143 2 11 47 96 513
4 12 35 100 278
8 10 25 96 126
24 18 47 96 143
Next we look at the effects of increasing the service-to-arrival Next we look at the effects of increasing the service-to-arrival
ratio. This means that EF packets should remain enqueued for less ratio. This means that EF packets should remain enqueued for less
time though the bandwidth available to the other queues remains time though the bandwidth available to the other queues remains the
the same. In this set of experiments the number of flows in the same. In this set of experiments the number of flows in the EF
EF aggregate was fixed at eight and the total number of queues at aggregate was fixed at eight and the total number of queues at five
five (four non-EF queues). Table 2 shows the results for 1500 and (four non-EF queues). Table 2 shows the results for 1500 and 160 byte
160 byte flows. Figures 3 plots the 1500 byte results and figure flows. Figures 3 plots the 1500 byte results and figure 4 the 160
4 the 160 byte results. Performance gains leveled off at service- byte results. Performance gains leveled off at service-to-arrival
to-arrival ratios of 1.5. Note that the higher service-to-arrival ratios of 1.5. Note that the higher service-to-arrival ratios do not
ratios do not give the same performance as PQ, but now 90% of give the same performance as PQ, but now 90% of packets experience
packets experience less than a subscribed packet-time of jitter less than a subscribed packet-time of jitter even for the small
even for the small packets. packets.
Table 2: Variation in Jitter of EF flows: service/arrival ratio varies, Table 2: Variation in Jitter of EF flows: service/arrival ratio
8 flow aggregate, 56 Kbps subscribed rate varies, 8 flow aggregate, 56 Kbps subscribed rate
WRR 1500 byte pack. 160 byte packet WRR 1500 byte pack. 160 byte packet
Ser/Arr 50th % 90th % 50th % 90th % Ser/Arr 50th % 90th % 50th % 90th %
PQ 1 3 17 43 PQ 1 3 17 43
1.03 14 27 100 178 1.03 14 27 100 178
1.30 7 21 65 113 1.30 7 21 65 113
1.50 5 13 57 104 1.50 5 13 57 104
1.70 5 13 57 100 1.70 5 13 57 100
2.00 5 13 57 104 2.00 5 13 57 104
3.00 5 13 57 100 3.00 5 13 57 100
Increasing the number of queues at the output interfaces can lead Increasing the number of queues at the output interfaces can lead to
to more variability in the service time for EF packets so we more variability in the service time for EF packets so we carried out
carried out an experiment varying the number of queues at each an experiment varying the number of queues at each output port. We
output port. We fixed the number of flows in the aggregate to fixed the number of flows in the aggregate to eight and used the
eight and used the minimal 1.03 service-to-arrival ratio. Results minimal 1.03 service-to-arrival ratio. Results are shown in figure 5
are shown in figure 5 and table 3. Figure 5 includes PQ with 8 and table 3. Figure 5 includes PQ with 8 flows as a baseline.
flows as a baseline.
Table 3: Variation in Jitter with Number of Queues at Output Interface: Table 3: Variation in Jitter with Number of Queues at Output
Service-to-arrival ratio is 1.03, 8 flow aggregate Interface: Service-to-arrival ratio is 1.03, 8 flow aggregate
# EF 1500 byte packet # EF 1500 byte packet
flows 50th % 90th % flows 50th % 90th %
PQ (8) 1 3 PQ (8) 1 3
2 7 21 2 7 21
4 7 21 4 7 21
6 8 22 6 8 22
8 10 23 8 10 23
It appears that most jitter for WRR is low and can be reduced by It appears that most jitter for WRR is low and can be reduced by a
a proper choice of the EF queue's WRR share of the output link proper choice of the EF queue's WRR share of the output link with
with respect to its subscribed rate. As noted, WRR is a worst respect to its subscribed rate. As noted, WRR is a worst case while
case while PQ is the best case. Other possibilities include WFQ PQ is the best case. Other possibilities include WFQ or CBQ with a
or CBQ with a fixed rate limit for the EF queue but giving it fixed rate limit for the EF queue but giving it priority over other
priority over other queues. We expect the latter to have queues. We expect the latter to have performance nearly identical
performance nearly identical with PQ though future simulations with PQ though future simulations are needed to verify this. We have
are needed to verify this. We have not yet systematically not yet systematically explored effects of hop count, EF allocations
explored effects of hop count, EF allocations other than 30% of other than 30% of the link bandwidth, or more complex topologies. The
the link bandwidth, or more complex topologies. The information information in this section is not part of the EF PHB definition but
in this section is not part of the EF PHB definition but provided provided simply as background to guide implementers.
simply as background to guide implementers.
A.3.2 VLL service A.3.2 VLL service
We used simulation to see how well a VLL service built from the We used simulation to see how well a VLL service built from the EF
EF PHB behaved, that is, does it look like a `leased line' at the PHB behaved, that is, does it look like a `leased line' at the
subscribed rate. In the simulations of the last section, none of subscribed rate. In the simulations of the last section, none of the
the EF packets were dropped in the network and the target rate EF packets were dropped in the network and the target rate was always
was always achieved for those CBR sources. However, we wanted to achieved for those CBR sources. However, we wanted to see if VLL
see if VLL really looks like a `wire' to a TCP using it. So we really looks like a `wire' to a TCP using it. So we simulated long-
simulated long-lived FTPs using a VLL service. Table 4 gives the lived FTPs using a VLL service. Table 4 gives the percentage of each
percentage of each link allocated to EF traffic (bandwidths are link allocated to EF traffic (bandwidths are lower on the links with
lower on the links with fewer EF microflows), the subscribed VLL fewer EF microflows), the subscribed VLL rate, the average rate for
rate, the average rate for the same type of sender-receiver pair the same type of sender-receiver pair connected by a full duplex
connected by a full duplex dedicated link at the subscribed rate dedicated link at the subscribed rate and the average of the VLL
and the average of the VLL flows for each simulation (all sender- flows for each simulation (all sender-receiver pairs had the same
receiver pairs had the same value). Losses only occur when the value). Losses only occur when the input shaping buffer overflows but
input shaping buffer overflows but not in the network. The target not in the network. The target rate is not achieved due to the
rate is not achieved due to the well-known TCP behavior. well-known TCP behavior.
Table 4: Performance of FTPs using a VLL service Table 4: Performance of FTPs using a VLL service
% link Average delivered rate (Kbps) % link Average delivered rate (Kbps)
to EF Subscribed Dedicated VLL to EF Subscribed Dedicated VLL
20 100 90 90 20 100 90 90
40 150 143 143 40 150 143 143
60 225 213 215 60 225 213 215
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 61 change blocks. 
341 lines changed or deleted 324 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/