IP telephony is taking off, big time. But quality of service is still a universal concern (read: a universal problem). It's a problem for long-haul "phone to phone" IP voice carriers, seeking to stay ahead of fast-growing demand. It's a problem for large enterprises, seeking to exploit today's IP telephony 'PBX' solutions (some profiled in this issue) over networks already freighted with growing data traffic. Ultimately, QoS is a concern to every stakeholder in the vision of 'all points everywhere' Internet telephony - everyone who's eager to benefit from the future of web-mediated telephony, the web-enabled contact center, transparent teleworking, and other killer apps.

It's a dollars and cents issue. Give people better quality in any dimension (better sound quality, better application availability, etc.) and they spend more time using your apps and services. Small quality improvements can translate directly into vastly improved revenue and bigger market share. Look at how wireless has grown, just in the past three years, at least partly as a result of the marginally better audio quality available with digital service. Similar paradigm-shifts - and new applications - lie on the far side of every significant improvement in service quality that we can anticipate engineering. Internet radio, video, telepresence - all stuff that's out there now, waiting for us to surpass whatever QoS threshold turns out to make them explode. And beyond them, new apps, that nobody's dreamed up, yet.

It's not all about "surpassing threshold barriers," either. Smart money says that although critical thresholds clearly exist, perceptible improvements in service quality tend to continue inflecting usage upwards in more or less linear fashion, between threshold bumps. When you're talking millions or billions of minutes per hour, the cost of a small infrastructure improvement that improves quality by 1% can easily be offset by the additional revenue it lets you capture.

Hold on, you may be thinking. Are you talking about QoS? Or are you talking about bandwidth? Clearly, the two are linked. Increasing bandwidth is one way to achieve QoS - popular at present, because convergent network usage is low enough so that it's still economical (or at least, "affordable, given all the cash we got from the IPO") to build networks whose bandwidth exceeds demand by a significant margin.

But that's not going to last. As convergence technology and services become monetized, and eventually commoditized, folks (both service providers and end-user network managers) will feel obliged to scale bandwidth and other dimensions of throughput/availability in closer approximation to actual demands. Meanwhile, an explosion of new applications is coming to chew up network overhead, just as fast as we can build it in. Today's approaches to bandwidth overprovisioning and careful, deliberate network traffic management are likely to be foiled by the fast-changing traffic picture on future, multi-application nets. And "QoS by manual control and forklift upgrade" is cost-inefficient; as well as philosophically abhorrent. It's way too last-century for next-gen enterprises and service providers who want to grow their networks organically and focus attention and capital on applications, rather than basic issues of service.

Which means that QoS considerations will never go away. Not with broadband. Not with fiber-to-the-curb. To folks still enamored of the George Gilder prediction that "bandwidth will be infinite and free," we say a quiet, philosophical "so what?" Consider the evolution of the PC. Does the 1 GHz machine on your desk run perceptibly faster or slower than the 1 MHz Apple II you owned as a teenager? Hard to give a clear-cut answer, isn't it?

QoS is a complex and vitally-important problem-set. And yet ... And yet many of our explorations into the QoS puzzle - particularly inquiries addressed to major IP voice carriers - seemed to reveal very little anxiety about the issue. Does this mean carriers have a blind-spot for QoS? That they don't see that "selling IP voice minutes cheap to conventional carriers" is a self-limiting commodity business? That "IP voice QoS" (something that can be addressed affordably by manual traffic-shaping and bandwidth overprovisioning) is just a short term way of looking at the problem? That greenfield carriers' (indeed, any carriers') long-term survival depends on being able to deliver multi-application/multimedia QoS in increasingly complex packages to increasingly diverse markets? Or are they just ... well ... behaving like carriers? Which is to say, are they just depending on technology improvements to push and market pressures to pull everything in the right directions?

It was only as we pushed deeper, speaking with hardware and software manufacturers, that we began getting some traction for the idea that holistic QoS was a) difficult, and b) scarily important. And we learned about some fascinating product initiatives that anticipate the needs of next-gen private and public networks for holistic solutions.

COMPLEX ISSUES
What exactly is QoS? It's a many-limbed beast: difficult to hog-tie with a single lariat. Conceptually, some of the issues at stake are as follows:

At the lowest level, QoS is about providing an environment that preserves the isochronicity of a signal - the signal goes in and comes out, undistorted, perceptually in "realtime." In terms of IP voice (and similar realtime media traffic such as IP videoconferencing), this means developing strategies to reduce and regulate end-to-end delay in the media processing system and the IP network. Many kinds of delay figure in perceived quality; among them, codec and packetization delay (the amount of time it takes to compress and packetize a snippet of sound), transmission and buffering delay, and routing delay. Also of concern are packet loss (which can be construed as 'infinite delay in packet arrival') and jitter (variations in delay between succeeding packets).

At a slightly higher level, QoS engineers look at call/session setup and teardown. Here, the concern is that signals governing the exchange of media streams are processed reliably.

At a higher level still, IT managers (and ASP engineers) worry about application performance - can the application as a whole derive sufficient performance from the network to function in an acceptable manner? Will groups of applications function acceptably in tandem, even if they make vastly different demands on bandwidth and network response? Can the app itself support the demands for media processing and throughput placed upon it by connectees?

At the most global level, will the network itself be available, and can it be provisioned, policy-managed, and cost-accounted/billed-for in practical ways? Can it protect itself against unanticipated usage that contravenes policy?

As you can see, just getting the voice back and forth is only part of the problem. When considered in real terms - of an IP network supporting multiple applications, including realtime transport of point-to-point voice/video - QoS encompasses many things: operating systems (real-time scheduling, threads), communications protocols, data networks, scheduling and traffic management issues, etc. Indeed, a holistic QoS strategy must encompass the workings of all seven layers of the Open Systems Interconnection (OSI) Model, as well as every network element from end-to-end. Any QoS "guarantees" are only as good as the weakest link in the transmission "chain" between a source of voice/data traffic and its destination.

For a QoS architecture to be successful, there must be some quantifiable (not to mention verifiable) level of assurance that the traffic and service requirements of each network component (e.g., an application, host, or router) can be satisfied, even though each component must interface with other components, each with its own set of traffic and service requirements. This points towards complex schemes for quantifying QoS. Ultimately, it points towards quantifying QoS in the second person: trusting machines to mind themselves, play watchdog, and work out the snarls, tangles, and billing issues at the end of the day.

Will this work in the real world? Well, what happens today, when some multivendor network or telephony service or subsystem goes down, and you call to snarl at one of the providers? 'Our NOC says nothing is wrong!' is what happens. Finger pointing happens. It's not pretty. Ultimately, to be an economically viable service, you need to build SLAs that humans can make judgements about. Customers have to know what they're buying and they must be confident that their service will be stable.

BANDWIDTH VS. PRIORITIZATION
As noted above, the fundamental trade-off in quality of service has always been between bandwidth, on the one hand, and traffic engineering or prioritization on the other. If you have unlimited bandwidth, then you have perfect quality of service for all traffic flows. As bandwidth becomes more constrained, traffic engineering and prioritization become more important. In real networks, both are always relevant.

Predictably, therefore, two global QoS strategies - one linked to bandwidth, the other to prioritization - are currently prevalent: Integrated Services (resource reservation), where network resources are apportioned according to an application's QoS request, and subject to bandwidth management policy; and Differentiated Services (prioritization), where network traffic is classified and apportioned network resources according to bandwidth management policy criteria. To enable QoS in this latter case, network elements give preferential treatment to classifications identified as having more stringent requirements. Thus is born the concept of Class of Service (CoS). Different applications are associated with two or three or more grades of service.

Some argue that CoS is a fiction, since we're not talking about real, established services but simply arbitrarily defined ways of forwarding packets. ("If the header looks like X then hold on to it for a millisecond. But if a bit in the header is set to 1, then send it first.")

These types of QoS can be applied to individual application "flows" or to flow aggregates. A "flow" is a stream of packets - an individual, uni-directional, data stream between two applications (sender and receiver), with the packets all uniquely identified by a "five-tuple" (they share the same transport protocol, source address, source port number, destination address, and destination port number). An "aggregate" here is two or more flows. Each flow has something in common, such as any one or more of the five-tuple parameters, a label or a priority number, or authentication information.

Different kinds of applications and network topologies dictate which type of quality of service is most appropriate for individual flows or aggregates. The most popular QoS protocols and algorithms are as follows:

ReSerVation Protocol (RSVP). Provides the signaling to enable network resource reservation (Integrated Services). Generally used on a per-flow basis, though it's also used to reserve resources for aggregates. RSVP makes a great effort to provide the closest thing to circuit emulation on IP networks. It's been used in videoconferencing for years. But in order for integrated services to work well, the router must maintain state information on each flow; the router determines what flows get what resources based on available capacity. RSVP doesn't have much scalability (processing must be done on every individual flow on the core Internet routers) and it lacks good policy control mechanisms.

Differentiated Services (DiffServ). A coarse and simple way to categorize and prioritize network traffic (flow) aggregates. Instead of maintaining individual flows on all routers, the flows are aggregated into an aggregate flow that receives "treatment" (per class or per service state). Service classes are identified, and each packet is marked to identify it as belonging to a particular service, then sent through the network. Each router in the path must examine the packet's header to determine how it will be treated (hold it in favor of a high priority packet or let it go now).

A minimal DiffServ system demands "admission control" (the network has to be able to refuse customers when demand exceeds capacity), "packet scheduling" (a method for treating data from different customers as needed), "traffic classification" (sorting streams into "substreams" each of which gets different treatment), and "policies" and "rules" (for allocating the network's resources).

Multi Protocol Labeling Switching (MPLS). Favored by Cisco, Juniper, and Avici, this provides bandwidth management for aggregates via network routing control, according to labels inside (encapsulating) packet headers. MPLS routing establishes "fixed bandwidth pipes" similar to ATM or frame relay virtual circuits, but with MPLS you're dealing with "coarse levels" of QoS - it's not actually as fine grained as the virtual circuits and provisioning of, say, ATM.

MPLS resides only in routers and is multi-protocol, so it can be used with network protocols other than IP (ATM, IPX, PPP, or frame relay) or even directly over the data-link layer.

MPLS is now a sort of standard. Avici, Juniper, Cisco, and some other vendors have gotten together and demonstrated interoperability of their MPLS-enabled equipment through a third party, George Mason University's Internet Lab.

MPLS may in fact be the "the winner" in the QoS protocol contest, if only because of the huge companies lining up behind it. But while QoS protocols vary, they are not mutually exclusive of one another. On the contrary, some of them (MPLS and DiffServ) are said to complement each other.

SERVICE PROVIDERS NOT WORRIED ... YET
Greenfield next-gen voice carriers - parties hoping to cut in on the PSTN's (i.e., the Tier 1 LD carriers', the BOCs', the PTTs', the ILECs' and CLECs', etc.) combined $80 trillion in global annual revenue - are betting the farm on being able to deliver good-quality voice. You might think that would mean they'd be frantic about QoS technologies. But in talking with several of the largest carriers, it seems this is not the case. They're wary of jumping on new QoS technologies before these are standardized. And they seem to be finding that a combination of overprovisioning and more-or-less manual traffic shaping is an adequate solution to QoS problems in the short term. All of the carriers we spoke with are actually using the (public) Internet to carry substantial traffic, subject to quality monitoring and fallback - either to private data links, private TDM links and equipment, or PSTN service - in the event of quality shortfalls.

Deltathree, one of the most respected IP communications networks, has renamed its consumer division IConnectHere (New York, NY - 212-500-4850). They offer PC-to-phone, unified messaging, and worldwide calling.

I spoke with Mark Gazit, executive vice president of technology and CTO of Deltathree, to fathom their QoS secrets.

"There is no big secret," says Gazit. "We efficiently load manage our communications, we have monitoring systems, and if need be, we will route over the PSTN using least cost routing."

"We do traffic shaping," says Gazit. "We have a private network that's tightly connected to the Internet in various places. It's a real network with light fibers that we lease in various countries, and we even have satellite links. We've built our own network. Our equipment can make a decision for each phone call to determine through which network the call will be routed: for the public Internet, where it's possible, or through our IP network."

Gazit says that they prefer to use their own network, but in places such as Ireland, it's much cheaper to use the public Internet.

"We use Cisco routers, Ericsson gateways and gatekeepers, and we've implemented some Cisco gateways," says Gazit. "And we're trying to be protocol agnostic, though we've begun to play with MPLS. We believe that the providers whom we are connected to will allow MPLS to be used everywhere and we want to be in a position where we can interconnect with their systems."

Gazit says that it's not enough to build the right network if you don't have the right tools to manage it.

"We do a lot of capacity planning," says Gazit. "Overprovisioning is an easy way to guarantee QoS, but it's an expensive way to deal with network quality. Profitability shrinks. It takes three months to get a new DS3 line between two continents and it might cost $100,000 a month. If we order it too late, then the quality of phone conversations will suffer for the previous month or two. Order the line too early, and it will cost us an extra $100,000 per month, which is unacceptable also. You must have the right statistical tools to predict the trend by examining repeating patterns of usage. Our management tools allow us to find the best timing for provisioning."

"Our tools are similar to those pattern recognition tools used in the technical analysis of the stock market," says Gazit. "So when we plan for new capacity and chart utilization graphs, we try to see what the usage trend is and when there is a 'buy' signal for us to buy more capacity. It's very much like the stock market. We even use a moving average. But there are no 'sell' signals, since we're always expanding!"

Gazit muses: "Of course, some people would say that the stock market is fast and efficient, and not all forms of technical analysis - looking at the patterns of the stock charts - are the right way to make money! Still, there was a lot of research done in this field, and I wonder if anyone who developed those tools ever thought that those algorithms would ever be used to do network management and graph analysis."

"The funny thing is, while such algorithms may not always work for stocks or commodities, they do work quite well in the IP world. This is because in our world, the traffic patterns are constant. These patterns can be used to predict short-term usage and long-term growth," says Gazit.

"I believe we are able to achieve our high quality because we actually can put intelligence both inside the network as well as the edges," says Gazit.

IConnectHere focuses on IP networks, right down to the last mile. They don't care if a stretch of the network is ATM, as long as their traffic is traveling unencumbered through it. "It would have been a gamble to bet completely on IP three years ago, but now I think everybody is convinced that IP will eventually be everywhere," says Gazit.

Gazit says that IConnectHere has only one class of service: "The best possible. An ISP has to provide various classes of service because otherwise people will clog its network with very high bandwidth demands," says Gazit. "In our case, voice traffic is not very demanding, about 12 Kbps to 15 Kbps. We will in the future be able to provide various classes of service, but when we're talking about VoIP only, this issue is not as important. We sell actual solutions, not bandwidth."

Over at edge2net, Inc. (Kirkland, WA - 425-822-7000), they provide IP and switched telephony to carriers, IXCs, ISPs, and international telecoms with a focus on the Asian market. (They average millions of international wholesale minutes each month to the Asia Pacific market in particular.) Where it makes sense, edge2net enters into mutually beneficial strategic alliances with both customers and suppliers.

Jeri S. Wait, edge2net's founder and co-CEO, says "We've been a TDM business with a backbone that loops the world from London through North America to Asia Pacific. But every six months we would test the quality of IP, trying to determine when would be the right time to launch into that market arena."

"About a year ago, we made the decision that the network was now stable enough and the quality of the product was there so that our customers would certainly entertain buying IP minutes from us," says Wait. "We launched IP service not because it's a cheaper way to provide international calling, but because it's a great platform for many future enhancements. With that, we developed a new strategy into the market and a new customer set."

Edge2net provides all of the back office services through their IP platform.

"We're a sort of IP telephony ASP or a network telephony ASP," says Wait. "Through our hosted services, we offer web-based billing platforms, web-based customer service platforms, and enhancements, whether it's voicemail, or fax services, or international roaming, or video."

Edge2net now has two networks: the first is a traditional TDM network of "big iron" Nortel Class 5 switches. "On top of that," says Wait, "when we launch in an open market - such as Singapore, Sydney, or Tokyo - this is where we put in our VoIP platform, which starts off with a Cisco 5300. From there we interconnect to our customers, and so from that platform we can meet customers to provide them enhancements. We can provide IP international gateway calling but we also tie that back to our traditional switches, so that when we send calls all our calling is still done over nailed up fiber, and we do very little over the direct Internet. The stability of the Internet is still very shaky."

Edge2net can interconnect customers via IP. Then the calls can go through their frame relay packet network, or even on an international conditional private line service to the end destination. They can also route directly through the Nortel switches linked in Hong Kong, London and North America.

If there's excessive IP traffic, they can switch calls over to the PSTN. They monitor traffic on an hourly basis. "We think we can match anyone in the industry as to having the best tools for examining a country's network and assessing how call completions are going, call quality," says Wait.

Mark C. Ozur, CTO for edge2net, says "I'm unconvinced that there's one solution for all QoS problems. One of the keys to our model is understanding how the transport makes a partner want to allocate a certain bandwidth. There's been a great deal of basic Cisco router prioritization queuing to get to the first level of QoS. MPLS will be important. It's still has to be proven in large scale deployments."

"We've been using a fairly controlled architecture, with conservative provisioning. There's no substitute for good engineering. We've proven that you can deliver very high quality service using VoIP, but you have to be more conservative in your overall network architecture; that is, as few hops between routers as possible. No more than two or three. IPv4 isn't very satisfactory, but when IPv6 is fully deployed you'll have a better public space in which to move realtime data," says Ozur.

"We use G.729 in a lot of places. We find that much less than 15 Kbps per conversation is unsatisfactory. We turn on RTP header compression and do some packet chunking. Our limit is 12 Kbps per call without the packet header and 15 Kbps with it. Claims of eight-to-one compression for IP calls are for the most part unrealistic. That will change and latencies through routers will get better too."

Another big player, ITXC (Princeton, NJ -609-750-3333) has sold IP voice minutes to major global carriers since 1998. Their customers use these minutes to carry some of their phone-to-phone traffic - in most cases, doing so transparent to customers. ITXC says they sell about five million minutes a day (a figure that's increasing 30% a year), much of it to premier Tier 1 carriers, for whom quality is extremely important.

What's amazing about ITXC is that they don't have a private network to carry their packets. Instead, 95% of the time they route carrier calls over the wild and woolly Internet. They still manage to maintain a QoS so high that the average customer making a typical phone call would never suspect it.

Moreover, ITXC uses no secret hardware or software. The IP telephony gateways they use around the world are a mix of equipment from Clarent, Cisco, VocalTec, and Lucent.

ITXC has a network operation center that manages "ITXC.net," which is their overlay network provisioned out of the real Internet. Its NOC glows with custom traffic-monitoring screens, displaying, in realtime, areas of congestion in color-coded rectangles. These screens tap into about 350 points of presence (POPs) in about 76 countries of ITXC's distributed network. Each POP and its associated gateways/gatekeepers may have anywhere from 30 to 700 lines sprouting forth into the local PSTN.

ITXC won't install a POP and a gateway at a location unless there's enough dedicated onramp bandwidth available to guarantee quality, says Mary Evslin, VP of marketing for ITXC Corp.

After an ITXC POP is deployed and tested, ITXC's network operations center monitors its quality 24 hours a day. It does this by pinging (sending out a file like a sonar "ping" to a POP and measuring the time that it takes to return). ITXC has a database of how long it should take to ping each of their POPs around the world. If a ping takes too long, they know that Internet congestion is building.

ITXC also polls live real-time call completion records. If, say, call completion from AT&T to Lebanon is 47 percent, then ITXC must be that good or better.

ITXC even has a database of each call's duration, comparing that to average call duration in various countries. Since people don't talk for a long time on a bad connection, if the average call duration starts dropping to a few seconds, it's an indicator that voice quality may be going down.

ITXC buys Internet access from the big guys who own pieces of the backbone: Cable & Wireless, TeleGlobe, UUNet, and InterNAP. With multiple providers, ITXC can instantly switch from one call path through the Internet to another to maintain voice quality. These routing decisions are made just outside of the backbone by IP gatekeepers consisting of Excel/Lucent switches. ITXC calls the whole process "Best-Value Routing."

On particularly bad Internet minutes of a particularly congested Internet day, ITXC might buy a few minutes of PSTN bandwidth from AT&T while they figure out the problem. When it's resolved, they simply cut off AT&T and go back to the Internet.

Evslin says that "standards bodies are talking about RSVP and DiffServ and all that, but none of that's really ready yet. Manufacturers are trying to make their routers interoperable in terms of recognizing protocols such as MPLS, but we need something right now. And when a universal QoS appears, all of the routers on the Internet must be updated, which isn't going to happen very quickly. Do you really think that routers in Pakistan are going to be upgraded at the same time as those in New York?"

"If our quality wasn't okay, the big carriers wouldn't buy our minutes," says Evslin. "We're used by all the major carriers in the U.S., Europe, China Telecom, Korea Telecom, PODT (Philippines Telecom). ITXC maintains its voice quality to Thailand, Yugoslavia, Peru, and other far-flung locales."

Evslin maintains that ITXC shouldn't be tied into any one gateway vendor. "They just have to be vendors with a large installed base and committed to interoperability," she says.

"Sometimes we may encounter a situation where something from a Clarent gateway has to go to another Clarent gateway. But we often have different kinds of gateways at the same location. In Singapore, for example, there might be two or three gateways: one's a Clarent, one's a VocalTec and one's a Cisco. It's all pretty complex, but until all equipment everywhere is interoperable, we have to route calls based on what hardware is at each POP, and take into consideration price and quality," says Evslin.

The company's newest services are ITXC Push to Talk and Suite Adeline. ITXC Push to Talk service is sold to e-commerce sites, and enables browsing customers to click on a site button and be immediately connected to the e-tailer's call center. Suite Adeline is an Internet Call Waiting service that operates on ITXC.net and is resold by Internet Service Providers.

"We believe that in ten years all communications will travel over the Internet," says Evslin.

PUSHING FURTHER DOWN
Next, we spoke with NetSpeak Corporation (Boca Raton, FL - 561-998-8700), a leading developer and marketer of advanced telephony solutions for Internet protocol (IP) networks. These are some of the people packaging large-scale IP technology (both software and hardware) into "carrier in a box" solutions.

Netspeak has a couple of service delivery platforms that provide call control and advanced features, typically for Cisco powered networks. The usual application for their long distance service delivery platform is phone to phone, wholesale and retail services for both toll bypass rate arbitrage kind of applications, and as a cost-effective platform for delivering long distance voice services.

Scott St. Clair, NetSpeak's VP of communications, says that "Our big customers are companies like China Unicom, Telenova, Telematrix, and other companies with extensive networks in a particular region. They use our software to manage their networks to deliver voice-over-IP in a long distance environment."

Surely, such folks would have a vision for the need for holistic QoS in fully-converged networks, wouldn't you think? But not really. St. Clair implies that the real heavy-lifting for QoS all happens further down in the technology than NetSpeak needs to be concerned with.

"In that environment," he says, "the Cisco gateways actually do most of the QoS work. Our software is primarily responsible for routing the calls, basically just telling the gateways where to send the packets from a particular phone call on the network. Our existing products use H.323. We have a new platform we're working on that uses SIP. SIP does have more hooks in it for QoS than H.323 does."

Most of these networks don't yet have the ability to do RSVP or DiffServ types of resource reservation or prioritization, says St. Clair. "So the way that QoS is dealt with on these networks is by overprovisioning them, and by not using public networks. These are private, tightly managed networks," he says, "and they work very well without resorting to anything exotic."

HOW'S THIS FOR EXOTIC?
Pushing down further, we began talking to infrastructure providers about QoS issues. And here, we hit paydirt - real traction, not only for the long-term idea that providers were going to have to deal with holistic QoS, but even strong recognition that bandwidth overprovisioning was going to need help, before too long.

There's a problem with "throwing bandwidth at the quality of service problem." How do you throw bandwidth, without repeatedly having to rip out and upgrade core components? What's needed is a cleanly scaleable router architecture - one that can grow from relatively small bandwidth, to relatively large, easily, in small increments.

Companies like Avici (N. Billerica, MA - 978-964-2000) recognize the problem, and are coming to the rescue with one of the few scalable core routers on the market, called the TSR.

"We felt carriers wanted to start of with a gigabit router today and over time grow it into a terabit router," says Avici's director of strategic marketing Esmeralda Swartz. "They want to be able to smoothly add capacity to the same box. Our unit has 40 slots, with each slot holding a card that can be an OC-48 or a OC-192 or whatever the interface would be."

"Also, when you finally need to add another whole TSR, you don't use the customer-facing interfaces to interconnect the two chassis. That uses up the revenue-generating interfaces simply to interconnect. Our unit, however, interconnects via the backplane so you're not using up the modules that you could be using to actually support customers or support revenue," says Swartz.

ONE-BOX SOLUTIONS
Among manufacturers, there's also traction for the idea that carriers - and enterprise convergence buyers - won't long be able to deal effectively with QoS issues through disparate, hand-integrated, manually-driven policies and products. There's a strong sense that QoS can and should be made "turnkey." We found several vendors building all-in-one solutions that comprise multiple QoS functions, including queuing, TCP rate shaping, policy setting, and caching.

One interesting all-in-one QoS device is PolicyPoint from Natural MicroSystems (Framingham, MA - 508-620-9300). Robert Stack, vice president of information systems and technology and Kent Lowell, director of marketing for the IP services management division filled me in.

NMS' PolicyPoint 1000 is an IP traffic classification engine and shaping platform for the aggregation and management of traffic between the public network and an enterprise, and ensures end-to-end QoS and CoS across packet networks. Sprint's Customer Systems Development (CSD) Lab has formally certified PolicyPoint 1000 so that it can be connected to a Sprint carrier network.

PolicyPoint transports voice, video, and data traffic between enterprise Ethernet LANs and public or private IP and ATM wide area networks (WANs). It does sophisticated traffic classification, metering, application-level traffic shaping, reporting and service level management. Because IP QoS and bandwidth allocation can be managed by customer, user, application type, and enforced by time-of-day policies, multiple voice, video and data services can seamlessly co-exist on a single network, while maintaining the quality and service level that users have come to expect and require.

Says Lowell: "What's interesting about PolicyPoint is that it combines all the functions of an application level traffic shaper with those of an ATM router. So over and above being just a normal router, it's also providing connectivity into an ATM fabric. It's taking full bursts off the Ethernet switch at 100 Mbps and at full duplex if the switch is set up that way, and breaking them up into 53-byte ATM cells."

"PolicyPoint is using 'per flow queuing', which means you can run hundreds of virtual queues that are all time-stamped and based on a policy, and you can set up a class of service for IP communications in general or specific applications off of these 100 Mbps bursts, and uniquely shape them into the ATM virtual circuits."

"So let's say you wanted to do a VoIP signaling VPN," says Stack. "PolicyPoint can actually extract whatever your signaling is - H.323 or whatever - it'll recognize it and map it into an ATM virtual circuit that's going off to a call control server somewhere. We can actually guarantee that 100 percent of every call signal will be recognized and serviced, so you can create a zero packet loss signaling service. That QoS mechanism alone will accelerate the revenue stream of any service provider who uses it."

"If you don't have this, and you're just using a traditional router with queuing, you'll end up having some percentage of packet loss," says Stack. "It may be low, perhaps just one or two percent, but you don't even want that on a voice service."

"We're currently using rock-solid ATM local loops to get to the backbone," says Lowell. "Just as in the voice-over-DSL model, the local loop is ATM because of the class of service and reduced jitter and breaking up of packets. ATM is going from a core network technology to a last-mile technology. The cores will probably be replaced by an MPLS switching fabric, which is not really routing per se, it's still simple switching - it's just MPLS switching instead of ATM switching."

"Each application demands a certain level of QoS," says Stack. "DSL is a classic example today. What most carriers are doing is to offer, on a single local loop, voice plus Internet access. If you think about it, that of course is not good enough for an enterprise. There has to be a third service, which is Intranet access."

"PolicyPoint is the beginning of what we think is a new group of equipment that's a combination of traffic shapers, firewalls, and routers that look at packets, provide some security elements and then explicitly allocate bandwidth and service levels to the IP flows," says Stack. "ATM then becomes a virtual circuit. You extract the different applications from the big IP bucket and map them to ATM for transport across the local loop to the carrier."

"Carriers base their services on virtual circuits," says Stack. "So you have the voice bearer channels all being mapped into a certain virtual circuit construct. The Intranet is mapped across ATM virtual circuits, and Internet is fenced off and serviced by yet another virtual circuit. So you end up with three virtual circuits, all going to different revenue services. And what that architecture allows them to do is 'layer on' the next revenue service when they're ready."

"So let's say that somebody wants to be an ASP," says Lowell. "They can go back to the customer and say 'We'll just throw in one more virtual circuit and map your IP flows into that virtual circuit to do the data center hosting.' The traffic shaper can then do, for example, zero packet loss for VoIP but less stringent 'best effort' service for Internet delivery."

ATM thus becomes a series of sluice gates, a series of virtual circuits imposing order on IP.

Cost? Using PolicyPoint you can connect one Ethernet to one T-1 ATM connection with an end user list price of $3,500. PolicyPoint uses an unchannelized ATM T-1 or E-1 circuit pipe, so the number of simultaneous "calls" depends upon your compression algorithm and whether you're using silence suppression.

QUIZZING YOUR QoS
Another one-box QoS solution provider, Sitara Networks (Waltham, MA - 781-487-5900) learned that managers were interested in an intelligent QoS solution for the edge of the network. What they weren't interested in was the multiple box approach, where the network manager has to buy, administer, manage, maintain, and, worst of all, coordinate and optimize multiple pieces of QoS hardware and software.

Sitara was inspired to take a completely new approach to QoS - their QoSWorks platform consists of a QoS appliance that can be used to integrate all of the QoS tools network managers need to manage diverse types of network traffic. QoSWorks is essentially an appliance, a combination of software and hardware. "We're shipping boxes to customers," says Vlad Sukonnik, Sitara's VP of technology. "They don't see what's inside."

QoSWorks is optimized for deployment at remote office locations where there is limited IT staff. It is typically deployed behind the router at the LAN-WAN interface and requires no changes to existing routing tables or reconfiguration of browsers or any other hardware or software in the network.

Once QoSWorks is plugged into the network, it is completely manageable from any location around the world through a standard web browser or terminal. Because QoSWorks sits in the data path, in the event of a hardware or software problem it is designed to fail to wire, ensuring the uninterrupted flow of traffic.

QoSWorks is easy to install - you just place an Ethernet cable that plugs into your WAN router into the LAN interface of the unit. Then you place the supplied cross-connect cable between the WAN interface and the router's interface. Currently, the unit will handle up to 1,024 separate classes/policies to enforce quality of service on your network.

Sukonnik says "QoS is definitely an open-ended question and a can of worms. Everybody has a unique view of what QoS really is. My answer is slanted toward enterprises, because that's where Sitara has hit a sweet spot."

"Customers look for a solution such as ours which allows them to prioritize and control application performance," says Vlad. "Our solution looks at the entire IP network, and it prioritizes and bandwidth manages all applications. We call it 'holistic QoS.' If only some applications played by the rules, the rules would be useless."

Sitara has an umbrella application, QoSDirector, that brings together all individual bandwidth management points into one picture. QoSDirector is the central point that polls the statistics out of QoSWorks devices (via SNMP), aggregates them, and presents the administrator with information concerning how the QoS is working. It contains a database that keeps track of all network devices and correlates policies to devices.

If a network administrator wants to know why his application is not performing well, QoSDirector can see all of the points in the network that a particular application's traffic has traversed. That information can be correlated with other statistics he can see immediately. Based on that, the network administrator can decide what the problem is.

If voice or data traffic reaches dangerous levels, the QosWorks devices can signal QoSDirector using basic SNMP alerts. Even before you can make a call, the system can determine whether there's enough bandwidth to support the call.

QoSDirector is very much in line with the IETF model of policy provisioning where you have a policy server and then have policy enforcement points in the network.

"You need to have one of our QoSWorks devices at every branch that has VoIP solutions deployed, since you need to have a holistic picture of your network before you know you have enough bandwidth for VoIP," says Sukonnik. He adds that when deployed in this fashion, the system can be adaptive. "You need to have a feedback mechanism so that when you deploy a policy, you can see its impact," he explains.