Weighted fair queuing and RSVP are technologies that can help improve the transport of time sensitive traffic like voice and video across networks with limited bandwidth. The document describes how weighted fair queuing prioritizes traffic by separating it into parallel queues and giving some queues higher priority. RSVP allows endpoints to reserve bandwidth for applications by identifying traffic streams so routers can give them priority. The author tests these technologies on their network and finds that using weighted fair queuing and RSVP improves the quality of their LiveLAN video conferencing sessions during periods of network congestion.

1. PictureTel
RSVP and Weighted Fair Queuing
John Bartlett, PictureTel Corporation
June 2, 1997

2. For these data streams, the delay time through the network
Weighted Fair Queuing and RSVP (network delay), and the variations in that delay time
(network jitter) are the most important parameters. If some
Overview of the data is lost or becomes corrupted along the way, the
Creating a network that provides high quality voice and receiving application does the best it can without the lost
video support requires the network designer to review the data, and continues. The corrupted or lost data is never
entire span of the network over which voice and/or video resent by the source.
will be carried. This typically includes a local area So the rule of thumb for computer data is ‘better late than
network (LAN), router, interconnections within that LAN, never’. The rule of thumb for video and audio data is
a wide area link or cloud, and another LAN at the far end. ‘better never than late’. For if audio or video data is
This paper is focused on the requirements of router based received too late, it is merely thrown away; its usefulness
networks, specifically those using limited bandwidth wide has been lost.
area links. Here we look specifically at weighted fair
queuing and RSVP to see how these technologies will help Mixing the Two Traffic Types
improve the transport of time sensitive traffic (such as When data and video/audio streams are sharing the same
voice and video) across routers and links where limited network infrastructure, their divergent requirements
bandwidth is available, and where multiple traffic streams conflict. A router forwarding a large file transfer and a
are contending for the available router and bandwidth video stream may slow down both streams because of
resources. queue congestion. While this causes no great problem for
Internet
Backbone
Site ISP ISP Site
Local Router Router Router Local
Router
the file transfer, it creates havoc with the video session.
Establishing Priority for Video Traffic
How Priority is Accomplished
Why Priority is Necessary
To solve this conflict, the router must be able to recognize
Data Traffic Characteristics the audio or video data stream as a different type of traffic,
Most computer networking traffic is a result of one and give that stream priority over other data traffic types.
computer trying to move a fixed amount of data to another If a video session has priority, it will be sent ahead of the
computer over the intervening network. The requirements file transfer, to insure it arrives in time. The file transfer
for this type of transfer are that all the data be moved, that will take a bit longer to complete, but it will complete
there be no errors in the data, and that it get there as successfully, using the remaining available network
quickly as the network will allow. Network protocols have bandwidth.
developed that insure that the data is moved without error.
When network congestion occurs, these protocols slow A method of identifying the two types of streams is
down the transfer of data, and resend frames with errors, required, so that the router can treat the two data streams
until the transfer is complete. differently. Weighted fair queuing takes a step in this
direction, and RSVP provides an explicit method of
identifying individual session streams so the router can
Audio and Video Traffic Characteristics take appropriate action. Both these methods are described
Video and audio streams have very different characteristics below.
than data streams. The amount of data to be transferred is
directly dependent on the length (duration) of the audio or
video call. The data is sent at a fixed rate, a rate sufficient
to support the quality of the audio and/or video image
desired. And, in an interactive session, the data is required
to get to the far end in a timely and predictable manner.
RSVP and Weighted Fair Queuing, PictureTel Corporation 2

3. Weighted Fair Queuing When is it Not Useful?
Fair queuing will not help a network that is congested by a
What is Weighted Fair Queuing? very large number of similar traffic types. The backbone
Fair queuing is an algorithm for use in the routers, that of the Internet supports a large number of HTTP requests
gives equal access to each ‘conversation’ taking place over from thousands of different users. An in-house network
a particular port of that router. A ‘conversation’ (using the may be deluged by hundreds of PointCast update requests
IP protocol) is defined by a pair of IP addresses, and a pair on an hourly basis. Each client/server pair will create a
of UDP or TCP port numbers. Weighted fair queuing different conversation in the network, each vying for a
allows some conversations to carry more ‘weight’, or get a piece of the available bandwidth. Because each
higher priority than others on the same network. conversation has similar bandwidth requirements, fair
queuing will not significantly help this situation.
The traditional way for a router to forward traffic, is to
give equal priority to all packets. This is done by
forwarding each packet, as it arrives, into a single output
Applied to Video Conferencing
queue. This approach has the effect of giving higher Desktop video conferencing behaves like a relatively low
priority to conversations that are high bandwidth (high bandwidth demand application. The PictureTel LiveLAN
packet count) users. A conversation with a high packet V.3.0 client sends out approximately 30 packets per second
count sends more packets into the router, and hence will causing a demand for about 150K bits per second in each
have more packets queued in the output queue for direction (using a 174Kbps call format). This represents
transmission. 6% of a shared (half duplex) 10Mbps Ethernet, and 0.6%
of a shared 100Mbps Ethernet. However, it is important to
Fair queuing separates conversations into parallel output the quality of the LiveLAN session that each packet arrive
queues. These queues are then given equal access to the at its destination, and that it arrives in a predictable amount
output port. With this approach, a high packet-count of time.
conversation and a low packet-count conversation have an
equal chance of sending the next packet into the output If a network is supporting a few video conferencing
port. Thus, they would share the available bandwidth. sessions along with large file transfers, fair queuing can
provide sufficient additional priority for the video
. conferencing session to make the difference between a
Weighted fair queuing works the same way, except that good quality session and a poor one.
weighting is given to some queues over others. This
If, however, the bandwidth of any segment of the network
approach allows the router to assign a higher priority to
is overbooked with conversations of about the same
some conversations. The usefulness of this will be seen in
bandwidth requirements or less, fair queuing will not solve
the section on RSVP below.
the priority problem for the video conferencing session,
without the help of RSVP.
When is Fair Queuing Useful?
Fair queuing is useful when a mix of large file transfer type RSVP
traffic, and short interactive traffic is using a common
network. The large file transfers create conversations that What is RSVP?
use a large amount of the available bandwidth for an
extended period of time. If these conversations are given Resource ReSerVation Protocol (RSVP) is a protocol
slightly less bandwidth, the user is not greatly affected. being designed by the Internet Engineering Task Force
The short interactive traffic (Telnet, HTTP requests, (IETF). It is currently an IETF draft, which indicates that
application sharing, etc.) does not require a significant it is still under development and not an approved standard.
percentage of the available network bandwidth, but The RSVP page of the IETF can be found at:
benefits significantly from being able to get packets http://www.ietf.org/ids.by.wg/rsvp.html
through the network in a timely manner. Delaying these RSVP describes a conversation between end stations
applications affects users much more significantly. requiring a reserved segment of network bandwidth, and
The key advantage of fair queuing is that it is implemented the intervening routers of the network responsible for
locally on each router, and requires no network wide providing that capability. This conversation allows each
knowledge or interaction. Thus it can be implemented in router in the path between a ‘sender’ and a ‘receiver’ to
network hot spots with no changes to clients or other determine if it has sufficient bandwidth to support the new
network nodes. traffic request. If enough resources exist from end to end,
the connection is allowed.
RSVP and Weighted Fair Queuing, PictureTel Corporation 3

4. How Do I Use It?
Network Requirements
The ideal network will provide RSVP service on all routers
between the end points wishing to establish a video or
audio connection. However, over the next few years as this
technology is phased into existing networks, it is likely that
only a partial solution will exist. If the whole network
cannot be upgraded to RSVP, the network designer should
focus attention on those links where bandwidth constraint
or heavy utilization will likely cause traffic delays or
packet loss.
To use RSVP, the routers must be designed to support the
RSVP protocol. The routers will allow RSVP
conversations to be defined statically (specified through
configuration) or dynamically (specified through the RSVP
messages from sender and receiver clients as described
above.)
Weighted Fair Queuing
Figure 11, RSVP Protocol, from Weighted fair queuing must be enabled on each link in the
www.cisco.com/warp/public/724/4.html network that will support video conferencing applications.
The parameters for weighted fair queuing determine how
Each router that is supporting an RSVP connection is deep each queue will be, and how many dynamic queues
running weighted fair queuing. Each RSVP conversation will be available for unscheduled and scheduled traffic.
is then allocated to its own output queue for the port or
ports towards its destinations. The weights of these queues RSVP Configuration
is then adjusted by the local router based on the RSVP
RSVP must also be enabled on each link in the network
parameters. The queue weighting gives each queue
that will support video conferencing. The parameters
sufficient priority to insure that it gets the amount of
required for RSVP will include the maximum bandwidth of
bandwidth promised in the RSVP request.
the link that it is allowable to use for high priority reserved
Note that this bandwidth allocation does not carve out traffic, and the bandwidth that it is OK to use for each
bandwidth for the exclusive use of the RSVP conversation, individual high priority conversation. The first parameter
such as allocating a channel in a TDM environment. The allows the network manager to insure that some percentage
bandwidth is available to the RSVP conversation as a first of link bandwidth is always available for lower priority
priority. However, if the RSVP conversation is not traffic flows. If more bandwidth is requested through
currently using all the bandwidth it requested, other traffic RSVP than is available on a particular link at a particular
can use it. time, the reservation request will be denied. The client can
then either try the request again at a lower bandwidth, try
During the RSVP negotiation, messages are sent from the request again at a later time, or set up the call using
‘sender’ clients to proclaim that they are RSVP senders, ‘best effort’ support. ‘Best effort’ implies running without
and to define the path through the network to receivers. priority, in the same manner as other data traffic.
Reservation requests are initiated by receivers. These
requests are allowed or denied by the router nearest the RSVP Dynamic Requests
receiver. If the request is allowed, it is passed back Two clients that support the RSVP protocol will
upstream to the previous router in the sender-receiver path. automatically send RSVP requests into the network to
RSVP is a unidirectional protocol, hence this document request a resource reservation. These requests will be
refers to a sender and a receiver. For those applications managed by the routers that have been enabled to support
where clients are both senders and receivers, two separate RSVP.
RSVP reservations are established, one in each direction.
RSVP and Weighted Fair Queuing, PictureTel Corporation 4

5. If there are routers on the network path between the sender
and receiver that either do not support RSVP, or have not
had RSVP enabled, they will pass the RSVP messages
through transparently. This will then allow downstream or
upstream routers that do support RSVP to continue to
work. In this scenario a full end-to-end RSVP channel will
not be guaranteed. The routers that do not support RSVP
will be providing only best-effort support. However, if
these routers are not at bottlenecks in the network, the
session may be able to proceed with sufficient quality to be
useful.
Much of the client RSVP functionality resides in the
TCP/IP stack. System vendors are actively developing
these capabilities. WinSock 2 from Microsoft, for
example, will support RSVP, and will be shipped with their
Windows 97 release. WinSock 2 will enable many audio
and video tools to use RSVP reservations.
RSVP Static Requests
Reservations for a conversation can also be put in place
through static configuration. This means that individual
commands will be given to the router in lieu of RSVP
commands from the two clients, to establish and maintain a
reserved connection.
Static configuration has the obvious drawback of being
static, and requiring manual intervention. However, it may
be useful if a particular conversation is expected to occur
continuously, or at regular intervals. And it is useful if the
clients do not have the ability to request an RSVP
connection.
The RSVP static configuration parameters only need to be
entered into the two routers that represent the boundary of
the network, i.e. the router closest to the sender, and the
router closest to the receiver.
Network Issues
Implementing RSVP and weighted fair queuing in a router
requires the router to do more sophisticated processing on
each packet of data it receives. Currently available
implementations are software based solutions. This means
that the packet forwarding capability of your router is
diminished when RSVP and WFQ are turned on.
For routers that are supporting relatively slow links (such
as a T1) this may not be an issue. But for routers that are
supporting high speed links, this could mean that the
packet forwarding ability of the router becomes a network
bottleneck.
As router vendors move more functionality into hardware,
this performance limitation will be eliminated. In the mean
time, network designers should consider the router limits
with these protocols enabled, and plan accordingly.
RSVP and Weighted Fair Queuing, PictureTel Corporation 5

6. Fair Queuing Tests
PictureTel RSVP Test Bed Test Setup
Figure 1 indicates the lab setup used for testing. A T1 link
Test Objectives and Goals was used between two 10 Mbps links to insure that one
The goals for creating an RSVP test bed are: link can be saturated, creating a condition in which priority
is required to maintain a good LiveLAN session.
To learn about RSVP
To learn how to configure RSVP and what the parameters The traffic generator is used to create an artificial network
mean load across the T1 link. The traffic generator is set up to
send ICMP ping packets to the right-hand PC. These pings
To set up a traffic congestion situation, test out the effect
are then echoed back again, causing traffic congestion in
of WFQ & RSVP using LiveLAN, and determine if they
both directions.
are beneficial to a LiveLAN session.
The traffic generator is set up to create just a bit less than
PictureTel NSD Lab Test Environment the 1.5Mbps bandwidth available on the T1 link.
A test bed to test the effects of using RSVP and Fair
Queuing has been set up in the NSD lab at PictureTel. When the traffic generator and a LiveLAN session are run
This section outlines the configuration of this test bed, and simultaneously, the T1 link becomes congested, and many
shows the specific configuration commands used to frames are discarded due to queue overflow.
configure the routers for weighted fair queuing and RSVP.
Figure 22 - RSVP Test Bed
T1 (1.5 Mbps)
Cisco AdTran AdTran Cisco
2514 TU100 TU100 2514
Router T1 T1 Router
10 Mbps Ethernet 10 Mbps Ethernet
LiveLAN LiveLAN
PC PC
Traffic
Generator
Equipment
Qty Equipment
2 Adtran TU100 T1 DSU
2 Cisco 2517 Router running IOS version 11.2
2 Micron 166 MHz Pentium PCs running
Windows 95
2 LiveLAN Version 3.0
1 Network General Sniffer
RSVP and Weighted Fair Queuing, PictureTel Corporation 6

7. Test of RSVP
Test of Weighted Fair Queuing
Weighted fair queuing gives equal access to each
Table 1 shows the results of the Weighted Fair Queuing conversation flowing through an output port. The previous
test. The first line represents the quiet network state, example shows how this equal access tends to give priority
without any traffic generation. The round trip time is in a to the lower bandwidth stream. However, in a real
reasonable range for this set up, and the packet loss rate of network, many lower bandwidth streams are likely to be
the LiveLAN session is at 0, indicating that there is more competing for resources along side the larger transfers.
than enough bandwidth in the link to support this session Weighted Fair Queuing assigns each of these separate
without contention. Note that the round trip times shown conversations to its own queue. If the aggregate demand of
here are determined by the LiveLAN application, so they all queues exceeds the available link bandwidth, then each
represent round trip time at the application layer, including of those queues begins to back up, again affecting the
the effects of OS calls and the performance of the IP stack. quality of our video conferencing session.
The second line shows the effect of heavy traffic. The RSVP solves this problem by giving greater weight (more
round trip time has increased to nearly 600 ms, due to the priority) to the queues handling the video conferencing
output queue of the router being clogged with traffic. Each session (or which ever session is being managed through
frame that makes it through to the other LiveLAN client RSVP.)
has to wait for the full duration of the output queue, which
is clogged with full length frames. The packet loss rate has To test RSVP, we must create a traffic load that will look
increased to 4.8 packets per second (about 16%). A like many different conversations, of a bandwidth equal to
significant degradation of the LiveLAN video quality or smaller than the LiveLAN session. For this test, the
image results from the loss of packets in the link. traffic generator is modified to produce pings sourced from
20 different IP addresses, each running at 1/20th of the (1.5
Table 11 Mbps) rate. The amount of traffic is now the same as in
the previous test, but it is broken down into 20 separate
Traffic WFQ Round Trip Packets lost streams, each averaging about 75Kbps each. These
Gen. (ms) per second streams are smaller than the LiveLAN traffic stream, which
35 0 uses about 200Kbps.
√ 595 4.8
√ √ 35 1.7
Table 22
Traffic WFQ RSVP Round Trip Packets lost
The third line demonstrates the effect of enabling weighted
Gen. (ms) per Second
fair queuing. The round trip time has dropped back to a
reasonable range, and packet loss is substantially reduced. 30 0
The reason that weighted fair queuing works well in this √ 597 10.9 (*)
test is that the ICMP ping traffic (the traffic generator √ √ 95 7.9
traffic) is all being generated by a single IP source address, √ √ √ 65 0.2
and sent to a single IP destination address. The weighted
fair queuing algorithm assigns the ICMP traffic to one
queue, and the LiveLAN traffic to a series of separate
Looking at line 3 of Table 2 we see that the results of
queues for each open UDP port. Each of these queues is
running with weighted fair queuing enabled and no RSVP
given equal access to the output port. Because the
is better than without fair queuing, but that the packet loss
LiveLAN traffic is running at a lower rate (150K bps as
is quite a bit higher than in Table 1, and certainly
opposed to 1.5Mbps), it usually has no more than one
unacceptable for a good video conferencing session. The
frame in its output queue at any time.
round trip delay is higher than the equivalent line in Table
This test simulates an environment where there are a 1 because there are now many more queues competing for
relatively small number of large transfers (ftp file transfers the output port, causing contention between them for the
or the like) are contending with smaller traffic flows for limited resource of the output port bandwidth.
limited resources.
RSVP and Weighted Fair Queuing, PictureTel Corporation 7

8. In line 4 of this table, we see the effect of enabling RSVP. In this environment, the router is still able to give priority
The round trip time drops to the 60 ms range. When RSVP to traffic streams, however it has no way of understanding
is activated, priority is given to the queues assigned to the the instantaneous bandwidth available on the link, and so
LiveLAN traffic. These queues are given a more-than-fair its queue weightings may not provide the full bandwidth
share of the available bandwidth, because the RSVP requested.
connection has specifically requested that it be able to use
250Kbps of the port. This more-than-fair share is done by Performance of the Router
giving this traffic stream more weight in the queue dispatch
algorithm, hence the name weighted fair queuing. The Running WFQ may reduce the performance of a router. A
weighting is in this case determined by the RSVP protocol. best effort router forwards traffic based on the 20-byte IP
header information. Weighted fair queuing requires the
router to look deeper into the packet, to determine to which
Your Mileage May Vary specific conversation this packet belongs. This additional
The test bed results shown above clearly demonstrate the work may reduce the performance of legacy routers to the
value of RSVP. However, few real-world networks will be point where their aggregate packet-per-second performance
as straight forward as this test. The following issues need impacts the network utilization. The network designer
to be considered when setting up your network, to properly should be aware of this issue, and test his/her routers for
predict the outcome. performance before widely deploying weighted fair
queuing.
End to End RSVP
As mentioned before, the ideal network supports RSVP on
all routers between the two clients requesting a reserved
bandwidth. Since ideal networks are rare, RSVP is
designed to pass through routers that do not support it. On
those routers, best effort forwarding will take place. If they
support weighted fair queuing, the traffic stream will at
least be given that advantage, if not, traffic will be queued
with other traffic.
The key for video traffic is to insure that it reaches its
destination with only a minimal amount if jitter. Jitter is
defined as the variation in network delay from the average.
LiveLAN, for example, can sustain jitter of up to 150
milliseconds, but beyond that it drops the packets.
Router interfaces onto high speed backbone networks
where utilization is relatively low may provide sufficient
service through a best effort method. Router interfaces
onto a bandwidth limited link, such as a T1, should
definitely use RSVP due to the delays demonstrated above.
Point to Point Link vs. Shared Media
RSVP weights the queues of the weighted fair queuing
algorithm to give priority to the traffic stream requesting
bandwidth. The algorithm makes the assumption that the
entire bandwidth of that link is available for its use. In the
point-to-point T1 case described above, this assumption is
true. However, in a shared LAN environment, where there
may be three or more devices sharing the same physical
segment (and bandwidth), this is no longer true.
RSVP and Weighted Fair Queuing, PictureTel Corporation 8

9. TDM - Time Division Multiplexing - a method of sharing
Glossary: the bandwidth of a line where time is broken into a set of
HTTP - The Internet protocol used by web browsers to fixed length slots, and each conversation is allocated some
request objects and pages of data from servers. number of time slots. This method insures bandwidth for a
conversation is constantly available, but it does not allow
IETF - Internet Engineering Task Force - an international bandwidth that is allocated, but not currently in use, to be
standards body engaged in defining and standardizing used by other conversations.
specifications for the Internet.
UDP - User Datagram Protocol - a protocol used by
Jitter - The difference in network delay between one applications that do not wish to guarantee delivery (see
packet and the next. Jitter represents the variability in TCP). Packets are sent into the network, and delivered if
network delay caused by temporary congestion, changes in possible. A good network delivers a very high percentage
routing and other factors. of these packets, only dropping packets when line errors or
momentary congestion make it necessary.
LAN - Local Area Network - a network of high speed
shared or switched connections within a building or WAN - Wide Area Network - a network of high speed
campus. connections spanning multiple buildings or campuses,
often in diverse geographic locations.
LiveLAN 3.0 - A desktop video conferencing client for PC
platforms from PictureTel Corporation. WFQ - Weighed Fair Queuing - an output algorithm used
by routers to insure fair access to the limited output port
Network Delay - The time it takes a packet to travel from bandwidth by the various streams of traffic flowing through
the sending computer to the receiving computer. Network it.
delays should be under 50ms in a LAN, but may be as
large as 200ms or 300 ms in a WAN or Internet Winsock2 - WinSock and WinSock2 are implementations
environment. of the TCP, UDP and IP protocols from Microsoft,
designed to run on PC platforms.
RSVP - Resource ReSerVation Protocol - a protocol used
by routers to give some traffic streams (those with
reservations) more weight in the WFQ algorithm, thereby
insuring they get as much bandwidth as their reservations
allow.
TCP - Transmission Control Protocol - the protocol used
by most Internet data applications to insure the reliable
delivery of data. TCP works on top of IP (i.e. it uses IP)
and guarantees delivery of packets by giving each packet a
sequence number. Lost packets are identified and sent
again until they are successfully received.
Links to Web Pages on Weighted Fair Queuing and RSVP
Cisco white paper on queuing methods, weighted fair queuing and RSVP.
http://www.netcenter.no:80/CiscoEnterpriseSalesToolsCD/cc/cisco/mkt/ios/rel/110/cos_wp.htm
Cisco overview of weighted fair queuing and RSVP.
http://cio-europe.cisco.com:80/warp/public/724/4.html
NetManage paper on Weighted Fair Queuing
http://www.netmanage.com:80/support/manuals/cham60/c_chap2.htm#Weighted Fair Queuing (WFQ)
Cisco white paper on RSVP and Video Conferencing http://cio-europe.cisco.com:80/warp/public/614/18.html
Intel RSVP Trials White Paper
http://www.pentium.com:80/iaweb/pr/intern~1.htm
“RSVP: A New Resource ReSerVation Protocol” Zhang, Deering, Estrin, Shenker and Zappala Article written for
publication in IEEE Network Magazine. Postscript format, 22 pages in length.
ftp://catarina.usc.edu/pub/daniel/RSVP/LAN PC
RSVP and Weighted Fair Queuing, PictureTel Corporation 9