Browse By...  Technology/Topic  Vendor  Back Issues  Content  LAB TEST CENTER  TECH TUTORIALS  GLOBAL NETWORKS  N.P.N.  PRODUCT LEADERS  OPINIONS/COLUMN  Viewpoint  INDUSTRY PIPE  Visitor's Center  FAQs  Contact the Editors  Free Newsletter  Subscriptions  Marketing Services  Industry Front & Center  Reader Service  Custom Publishing  Real World Seminars  Vendor Strategies  Byte.com  CMPmetrics  Data Communications  File Mine  InformationWeek  InternetWeek  Network Computing  Planet IT  TechShopper  TechWeb News  Tele.com  WebTools  Winmag.com

May 21, 1996 By Fred Baker, Cisco Systems Inc. Real-Time Services for Router Nets [ Key Concepts | Inside the ISA ] The IETF's integrated services architecture lets IP internetworks handle real-time applications like voice and video It's enough to make net managers dream of early retirement: The CEO shows up one day and demands desktop-to-desktop videoconferencing for everyone in the company. Oh, and that interactive multimedia application? Give each employee a copy. Figuring out how to transport all this real-time data over the corporate net--well, that 's someone else's headache. Guess whose? And it can be a real doozy. That IP net the company spent millions installing is designed to transport LAN data, not delay-sensitive real-time multimedia traffic. Moving to ATM--the only scheme designed from the ground up to carry both--means ripping out all the networking gear and replacing it with a technology that's both expensive and still relatively untried. Time to start shopping for South Florida real estate? Not just yet. The IETF (Internet Engineering Task Force) is developing a suite of standards called the integrated services architecture (ISA), which permits networks to provide quality of service (QOS) transport over IP nets. ISA can be implemented through advanced congestion management and queuing algorithms that limit delay, jitter, and bandwidth consumption in the network. It also includes protocols, such as the Resource Reservation Protocol (RSVP), that make it possible to reserve bandwidth for particular applications. Together, these capabilit ies let IP networks handle real-time applications like voice and video. Implementing the ISA requires making software, and possibly firmware, upgrades to switches and routers. Both Bay Networks Inc. (Santa Clara, Calif.) and Cisco Systems Inc. (San Jose, Calif.) plan to release gear incorporating the ISA in September or October. INELASTIC ISSUES Depending on the application that generates it, traffic can be divided into two broad categories: elastic and inelastic. Elastic traffic is generated by applications that can adapt their behavior to ambient network conditions. For example, most TCP traffic--including file transfers, electronic mail, and World Wide Web searches--is elastic. Such applications as these use as much bandwidth as they reasonably can, but when faced with congested or low-bandwidth links they adjust gracefully. That's why it's possible to surf the Web using the same browser with either a 9.6-kbit/s modem or a T1 (1.544-Mbit/s) link. The application senses tha t less bandwidth is available and transmits data at a slower rate. Inelastic (also called real-time) traffic is generated by applications that can't adapt to network conditions without becoming less useful or changing the nature of the traffic itself. Broadly speaking, the ISA helps to make IP networks, originally devised for handling only elastic traffic, capable of transporting inelastic traffic. Conditions that can affect inelastic traffic include end-to-end delay, jitter, and bandwidth limitations. Different applications are susceptible to these problems in different degrees. For instance, a financial quoting system can't tolerate end-to-end delay, regardless of bandwidth or jitter. Brokerages often use reporting services that deliver the up-to-the-moment price of any stock or bond and allow brokers to conduct transactions electronically. The pricing information might arrive over a T1 landline connection within, say, 100 milliseconds. But if it comes through a T1 satellite link, th ere's an additional 540-ms delay, since the signal might have to travel 22,000 miles to and from the satellite four times. These 540 ms may not be particularly noticeable. But brokers who consistently receive information later and consistently take longer to transact each trade than they would without that delay will tend to react more slowly and to miss trades more frequently--and therefore to average less income. TIME ON THE LINE Jitter is the variation in the amount of time a message spends in the network before arriving at its destination. "Message" refers to the block of data a particular protocol sends and receives, which differs from protocol to protocol. In the TCP/IP suite, for instance, TCP messages are typically called "segments," IP messages "packets" or "fragments," and link-layer messages "frames." UDP (user datagram protocol) messages are generally called "datagrams." In a routed network, the amount of time a message spends traversing the network results partly from th e time required to transmit a message, partly from propagation delay, and mostly from queuing within the routers. Queuing introduces the greatest amount of jitter. Another factor is HDLC (high-level data link control) bit stuffing, which can extend a message on the wire to seven-sixths of its actual length. Packet video is an example of jitter-intolerant traffic. When video is transmitted over a packet network, it's first encoded by a hardware or software codec and then encapsulated in the network protocol and sent across the net. Video-encoding algorithms in the codec use the previous frame to generate each video frame, which means that the receiving station must have a sequence of frames before it can decode them. THE PLAYBACK POINT Because of jitter, the receiving station has to buffer voice and video traffic until it's reasonably likely that all frames have been received--the so-called playback point, where the receiving station converts the digital signal for display. Any frames that arrive later are simply discarded as too late. Discarded frames diminish the quality of the display; moreover, the frames occupy space in queues, delaying the rest of the traffic and possibly causing it to be discarded as well. The more jitter that can be reduced, the better the quality of such applications. Furthermore, since end-stations need large buffers to handle jitter, reducing it cuts the buffering requirements of those end-stations. Memory is expensive, so this cuts the cost of packet video solutions. Video is also highly bandwidth-sensitive, which means that to handle video well a network must not only limit jitter but also provide a minimum guaranteed bandwidth. To handle an application like a brokerage service, the net also should be able to provide guaranteed end-to-end delays. NO GUARANTEES Such traditional datagram networks as TCP/IP provide no service guarantees whatever. TCP or the application guarantees reliability in the IP suite. Below the transport layer, traffic loss occurs for any number of reasons, and retransmissions by protocols such as LAPB (link access procedure-balanced) can prevent timely delivery. Yet it's possible to provide several kinds of guarantees at the data link layer: bandwidth, per-hop delay, and acceptable interference (which can limit jitter). Providing these guarantees is what's meant by QOS networking, and it is the goal of the ISA. Currently, the ISA defines two kinds of services, and more are under development. Guaranteed service permits applications to obtain both bandwidth and delay guarantees and assumes that the network (or at least its key points) uses the weighted fair queuing algorithm. Controlled load service makes delays minimal and doesn't require particular types of queuing. To provide these guarantees, the architecture makes several assumptions. For example, it assumes that there is some traffic (inelastic traffic) for which guarantees have to be made. Other traffic is considered elastic, and the net work provides no guarantees for it--just best-effort service. To identify inelastic traffic, the ISA builds on the concept of flows, which is something like a TCP or SNA session but with two key differences: It's unidirectional, and there can be more than one recipient of a flow. Messages are associated with a particular flow according to their source and destination addresses, port numbers, and protocol types. Inelastic traffic is identifiable by flow. FLOW HANDLING To provide the service guarantees required for inelastic flows, router and switch software must be modified to handle flows. A typical router or switch today has two main components: one that figures out where to send messages, and one that switches them. The process of switching a message includes validating it, selecting the route, queuing it for transmission (generally using a first-in-first-out algorithm), and transmitting it. The process of determining where to send the message includes building the tables used in r oute selection and choosing among the available routes. The ISA expands that model in two ways: by modifying the route-selection procedure and by adding advanced queuing policy and flow admission with a setup protocol (see Figure 1). Under the ISA, once a switch or router has determined the destination of the message in the route database, the router also decides if the message is part of a flow. Each flow is associated with a queuing policy, so if the message is part of a flow, the router adjusts queuing to provide the right services for it. Figure 1: Routing, ISA-Style Routing in the integrated services architecture (ISA) involves three processes not found in conventional schemes. Packets are associated with a particular flow, and a QOS (quality of service) is established for each. Flow signalling is propagated across the network to ensure proper handling. Queuing adjustment is handled by a signaling protocol that communicates information about the flows between routers. The signaling protocol has two main purposes: to ensure that network resources are available to carry the flow and to install a queuing policy that meets its needs. QUEUING QUALITY Defining an effective queuing policy is a key component of the ISA. Today, most switches and routers use first-in-first-out queuing. While simple and speedy, this doesn't perform well when links are congested--that is, when the queues are deep--because the algorithm lacks an effective way to tell an application to slow down. At least on internetworks, this is a particular problem with bursty traffic. Burstiness isn't a problem on a lightly loaded LAN where there are no routing delays. But once traffic leaves the LAN, problems can ari se: In particular, delay-sensitive traffic ends up waiting behind long bursts of less delay-sensitive traffic. One way of resolving this problem is fair queuing, which calls for the switch to discriminate among traffic flows and to sort them, ensuring that no flow can take over the network link. Fair queuing also makes sure that flows using relatively little bandwidth are guaranteed minimal latency and that flows using more bandwidth can achieve approximately the same throughput, though at the cost of potentially increased latency. Fair queuing has an interesting side effect: It permits the switch or router to slow down unduly aggressive flows. This makes the network more fair for other traffic, particularly if it is elastic. In fact, networks can theoretically be made completely predictable if applications control the rate at which they send--which programs using TCP do naturally--and if all switches in the network use a fair queuing algorithm. In weighted fair queuing, a variant of f air queuing, each flow's bandwidth is weighted; therefore, real-time traffic gets exactly the performance it needs, inelastic traffic can be shielded from best-effort traffic, and best-effort flows can be shielded from one another. The catch is that weighted fair queuing can be slow because of the time it takes to sort the queues. RED ALERT Another way that switches can implement the ISA guarantees uses a variant of the Random Early Detection (RED) congestion control mechanism. Although not specifically designed to handle real-time traffic, RED can be extended to provide different service guarantees for different types of traffic. The theory behind RED is that most data-transport schemes are sensitive to loss and will at least momentarily slow down if some of their traffic gets dropped. This isn't a problem if the traffic is elastic (as in TCP), so having the router intentionally drop messages is a good way of slowing down this kind of traffic and eliminating network congestion. Furt hermore, if there's a mix of elastic and inelastic traffic, slowing down the elastic traffic helps improve the performance of its inelastic counterpart. But this approach also can cause problems if a significant percentage of traffic is inelastic. To see why, it helps to take a look at how TCP (and protocols like it) handle traffic loss. TCP sends messages in order; when the protocol stack in the receiving station gets a message, either it's the next message in the sequence or it isn't. If it is the next one, the protocol delivers all the data it can to the application, updates the next expected sequence number, and either sends an acknowledgment immediately or schedules one to be sent after a small delay. When the protocol stack in the sending host receives the acknowledgment, it checks to see what data has been acknowledged and determines whether the acknowledgment has been repeated. If so, a message was either received out of order or dropped. When a TCP sender detects a dropped message, it resends the message and then enters a slow-start phase, when it tests the network to find a rate at which it can send without dropping data. But in highly loaded networks, global synchronization can cause problems during this slow-start phase (see Figure 2). Figure 2: Global Sync Slowdown Global synchronization allows many network nodes to simultaneously transmit bursts (a). When traffic gets too heavy, routers attempt to slow some sessions by dropping messages and shifting into slow-start mode (b). When the nodes discover the network is no longer congested, they begin transmitting at full speed, clogging things up again (c). DATA WAVES Since data traffic is bursty, when messages start gett ing dropped this probably means that a temporary burst of data is traversing the network. If so, queues in the switches or routers are likely to be full. Once they start dropping messages, many TCP sessions simultaneously go into slow-start mode immediately. Network traffic slows down dramatically for a short time and then begins anew. The queues become congested again, and all of the sessions once more go into slow start. Because all of the slow starts occur at about the same time, they're synchronized. One solution would be to tell a single TCP session at a time to slow down and then measure the effect before slowing down the next session. That's exactly what happens with RED. The router queue is divided in two parts: one for normal operation (designed not to drop messages) and one to handle overflows. RED measures the average queue depth. When it's low, the overflow queue operates as a temporary buffer. When the queue depth rises, it begins to drop messages, using an algorithm that increases the pr obability that the current message will be dropped as the time since the last dropped message increases. In consequence, the greater the network congestion, the faster the messages will be dropped. Furthermore, the interdrop interval is long enough to prevent messages from being dropped until the TCP sender has had a chance to detect the loss and go into slow start. Extending RED to handle real-time traffic is fairly straightforward. Basically, the router simply drops messages at different rates for different flows, depending on their throughput and delay tolerance. BANDWIDTH ON RESERVE RSVP implements the ISA's admission and quality of service architecture. As its name implies, RSVP reserves network bandwidth and installs queuing policy for inelastic flows. When a station wants to reserve bandwidth for a particular path through the network, it sends a path message to the destination address. Each router along the route to the destination passes the message along. Since the message f ollows the same path that the sender's data will follow, it discovers which routers must be asked to provide the reserved bandwidth. The path message also carries information about the data stream that the sender wishes to transmit over the path. This information includes such things as the rate and size of the transmission burst. When a receiving station gets the path message, it thus has the information it requires to determine what type of bandwidth and network services it must reserve to get the data. Note that there may be more than one receiving station, if, for instance, the data is part of a point-to-multipoint videoconference. Armed with this information, the receiving station formulates a message called recv, which requests bandwidth from the network. This message gets forwarded to each of the routers along the path from sender to receiver. A router that gets the request first validates it, determining whether resources are available to provide the bandwidth requested. If not, the ro uter refuses the request. If resources are available, the router installs the queuing policy needed to manage the flow and forwards the request to the next router along the path. GOING UPSTREAM As these reservations are passed upstream to the sender, they're merged, ensuring that the data flow isn't replicated unnecessarily. Since the reservations are merged, the more stringent requirements are satisfied. No receiver will get worse treatment than it requests, but it may get better treatment. RSVP supports three types of reservations. Fixed-filter reservations establish a reservation on a path from a single source to its receivers. This is appropriate for flows, such as video, that have a separate continuous data stream from each sender. Wild-card and shared explicit reservations are used when senders alternate. One example is audio transmission, which needs bandwidth for only a single person to send at a time; the same bandwidth can be used by successive speakers in a conversation. The ISA also works with a number of other protocols developed by such standards bodies as the IETF and the ITU-T (International Telecommunication Union--Telecommunication Standardization Sector). The additional specifications define such matters as the transport of H.320 videoconferencing data across an IP network via the ITU-T H.323 and H.225 protocols, as well as an API (application program interface) for applications to request QOS networking via the Winsock II protocol, which includes a socket interface design for ISA. MISSING PIECES Although the ISA represents an elegant approach to a difficult problem, some pieces are still missing. In particular, its designers focused on audio and video traffic to the exclusion of other kinds of traffic that also could exploit such an approach. For example, protocols like SNA and Appletalk might benefit from guaranteed-bandwidth tunnels through a multiprotocol network. It would be useful to define a service that doesn't ask for a specif ic bandwidth or for treatment as real-time traffic but informs a fair queuing network that the particular tunnel is carrying several best-effort traffic flows and should be weighted as such. This approach also could be used to prioritize network flows that are not tunnels but need improved service. The IETF also is developing a LAN management protocol that will support H.323 videoconferencing over a LAN. The LAN manager basically is a way for RSVP reservations to be set up on a shared-medium LAN, such as Ethernet or FDDI. This is intended to control the amount of traffic with guarantees that's crossing the LAN from all sources. Finally, work is in progress to define a way of authenticating flows, to enable advanced reservations, and to limit who can obtain services from the network. Fred Baker is senior software engineer at Cisco Systems Inc. (San Jose, Calif.) and the chair of the Internet Engineering Task Force. [ Home ] [ Registration | Subscriptions ] [ Contact Us | E-Mail ] Home Contact Editors Lab Tests Registration Tech Tutorials Buyer's Guide Global Networks Opinion / Columns FAQs Subscriptions