Picturetel RSVP and Weighted Fair Queuing


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Picturetel RSVP and Weighted Fair Queuing

  1. 1. PictureTel RSVP and Weighted Fair Queuing John Bartlett, PictureTel Corporation June 2, 1997
  2. 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. 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. 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. 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. 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. 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. 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. 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