QoS Takes Shape
[All,
Would anyone care to separate the hype from the substance here, beyond that which the author attempts?
Regards, Frank Coluccio]
September 29, 1998
INTERNETWEEK via NewsEdge Corporation : It's the
shape of things to come. A group of quality-of-service
protocols from the Internet Engineering Task Force
ultimately could transform the Internet from its
frustrating first-come, first-served mode into a more
business-friendly environment.
The hope is that with quality of service (QoS), a network
manager could, for example, order a high-end "gold" IP
WAN service for an SAP application, a mainstream
"bronze" service for e-mail and something in between
for bulk file transfers.
The race to morph the Internet into a business-class
WAN for all seasons is driven by the growth in
IP-based virtual private networks and intense
competition among ISPs to offer different classes of
service.
Some of the biggest names in IP networking and
computing-including Bay Networks, Cisco, IBM, Intel
and Microsoft-are behind the new QoS protocols:
Differentiated Services (Diff-Serv), the Label
Distribution Protocol (LDP) and the newly resurrected
Resource Reservation Protocol (RSVP).
But here's the rub. Even if every single Cisco router and
Microsoft NT Server came equipped with emerging QoS
standards like Diff-Serv for classifying traffic, there's
still no guarantee QoS will work across different
enterprise IP WANs or from one ISP's network to
another. So, a gold-class SAP transaction over the
Internet may not get round-trip, first-class treatment if a
company's trading partner rides a different ISP network.
"The real trick for QoS is [finding] a way to extend it for
data that traverses two or more network providers,"
says John Lawler, VPN product line manager at
Concentric Network Corp., a network provider that
specializes in VPN services. "That's the big catch."
Large companies like $1.9 billion Merrill Lynch are
keeping a close eye on QoS. "There is value in
segregating important traffic from not-so-important
traffic," says Nick DeVito, vice president of network
strategy and planning at Merrill Lynch, which runs a
large IP backbone. "If these [QoS] capabilities are
administratively manageable, we will look at them and
implement them."
The problem with QoS is politics, not protocols.
Diff-Serv, LDP and RSVP technologies cover everything
from the edge to the core of the WAN. Sure, for ISPs to
create QoS services, they must synchronize on QoS
standards like Diff-Serv for their routers, but they also
must negotiate peering arrangements that ensure that
these new classes of traffic get consistent treatment
across the Internet and settle the financial side of
transporting one another's traffic at a gold, silver or
bronze level.
"If someone is sending packets at a certain rate, how
[does an ISP] bill back to that network?" asks Bob
Moskowitz, senior technical director of the International
Computer Security Association Inc.
And peering is more than just a wink and handshake.
"The difficulty with peering is that everyone has a
different set of rules," says Mike Gaddis, executive vice
president of engineering and chief technical officer at
Savvis Communications Corp., an ISP. "It's an
independent negotiation each time you want to talk to
some other service provider, and you might have great
connections with some and not with others."
That one weak link in the chain could trash a QoS
transmission. "Even if you put in a super-duper QoS
service, if at an exchange point a voice packet is
dropped because of congestion, it's lost forever,"
Gaddis says.
More than likely, major ISPs will team up with one
another to extend their future class-based services as
widely as possible throughout the Internet. Others may
play catch-up for a while. "It's in the best interest of
large backbone providers to better serve their
customers," says Brandon Ross, chief network engineer
at Mindspring Enterprises Inc., an ISP.
With today's generic, non-QoS IP services, the story is
much the same: ISPs can only promise uptime
guarantees within their own IP "cloud." So, unless a
company and its trading partners subscribe to the same
ISP network, there are no guarantees. Without the tools
of QoS protocols like Diff-Serv and LDP for classifying
and engineering traffic loads, until now all ISPs have
been able to do is over-engineer their backbones with
extra capacity to head off congestion problems.
Tool Time
The concept of QoS for IP isn't new. Today, you can
plug in a bandwidth management or packet-shaping tool
like Packeteer Inc.'s PacketShaper to speed up
transactions over your WAN, or fiddle with the
proprietary QoS protocols that come packaged with
your Cisco router. The trouble is, software products like
PacketShaper aren't considered long-term solutions, and
router QoS options today work only within a single
vendor's product line.
Bandwidth managers are the most popular method used
by network managers to ensure that a hungry app gets
enough bandwidth.
About 34 percent of 100 network managers recently
surveyed by consultancy Renaissance Worldwide Inc.
say they run bandwidth management devices today-and
another third are testing them. Most deploy these
devices for balancing the traffic load on more heavily
congested hot spots like back-end server farms,
Internet-access router connections or branch-office
access router connections, says John Morency, a
principal at Renaissance.
Aside from such bandwidth stopgaps, there are
router-based approaches like so-called Layer 4
switching for prioritizing traffic by application, and
proprietary QoS techniques like Cisco's for queuing up
traffic based on a limited number of classes and for
randomly dropping packets when congestion occurs.
Then there's Cisco's Committed Access Rate protocol,
which looks a lot like Diff-Serv. But these methods, as
well as those from Bay Networks, 3Com and others,
work only within a single-vendor router environment.
That's where Diff-Serv comes in. Diff-Serv uses a
common language to mark packets with their proper
priority or class. Diff-Serv provides a standard way to
encode the so-called ToS, or type-of-service, header in
an IP packet to reflect its priority or class. There are
eight different classes of service in the Diff-Serv
protocol, so as long as different brands of routers speak
Diff-Serv, they should be able to consistently handle
different classes of traffic.
"If the Diff-Serv router sees that the packet is from an
SAP application, then it would label the ToS header with
the appropriate" level of service, says John Shaw, vice
president of marketing at router maker NetCore Systems
Inc. "Then it might get put in a higher-priority queue."
Diff-Serv is really just a labeling system to trigger QoS
along the traffic's route, Shaw says.
"It doesn't actually provide the QoS-it just enables
something else to provide QoS," he says.
That "something else" could be IP routers in the WAN
backbone that understand Diff-Serv. "When a router
gets a packet that says 'I'm voice, be nice to me,' the
router puts it in the correct queue and treats it kindly, "
says Fred Baker, IETF chair and senior engineer at
Cisco.
Unlike RSVP, which has been shunned by ISPs for not
scaling to the Internet, Diff-Serv is a lightweight
protocol that operates better across the WAN. It groups
packets with a "gold" rating, for instance, which saves
on router capacity.
ISPs initially will do the dirty work with Diff-Serv,
setting up their routers to handle the ToS headers based
on their service level agreements with enterprise
customers. Eventually, network managers will configure
Diff-Serv in their own edge routers, industry experts
say.
But don't expect end-to-end QoS to come overnight.
"The trick here is that all it takes is one carrier along the
path not yet supporting Diff-Serv, and there's a weak
link in the chain," says David Passmore, a principal at
NetReference, a consulting firm. "There's going to be a
transition period. "
Diff-Serv is about to hit the standards track at the IETF.
Right now, it's still in the draft stage.
3Com has an early version of Diff-Serv packed into its
routers, and other router vendors such as Cisco, Torrent
Networks Inc. and Xedia Corp. are beta testing it in their
devices. In addition, several ISPs, including Concentric
and Uunet Technologies Inc., are acting as Diff-Serv
beta sites. Look for router vendors to add Diff-Serv to
their operating systems in early to mid-1999.
Diff-Serv-based services could begin arriving later next
year.
Many ISPs are anxious to finally get Diff-Serv up and
running. "The attraction of Diff-Serv is that it's a
mechanism for us to shape bandwidth by traffic type,"
Concentric's Lawler says.
RSVP, meanwhile, has been revived as a QoS
technology, thanks in part to the attention surrounding
Diff-Serv. Although RSVP was a proposed IETF
standard for some time and it's been available in Bay
Networks, Cisco and 3Com routers, RSVP never really
took off. That was mostly because RSVP requires every
router along the data path to handle and store
information about every data flow. "RSVP was designed
to work within a single ISP cloud. That was a
fundamentally flawed design," Lawler says.
RSVP requests bandwidth on behalf of an app like SAP.
It's considered more of an intra-enterprise protocol
today, but it may have a broader role as the QoS
protocol at the edge of the network, with Diff-Serv in the
core WAN backbone.
And with Microsoft planning to pack both RSVP and
Diff-Serv protocols in the upcoming Windows NT
Server 5.0 release, RSVP finally may see the light of day
in IP networks. RSVP could ensure that an NT server or
server farm gets plenty of bandwidth, speeding up
access. It's all in the API, the code that ties the
protocols to the operating system. "Apps don't have to
know anything about RSVP," says Ron Cully, product
manager for Microsoft's NT Server communications
team. "RSVP allows apps to specify things they want
from a network, and we map [the requests]
appropriately."
Both Diff-Serv and RSVP could work in the LAN, too,
but given the wealth of local bandwidth today, it isn't
likely these protocols will be needed there anytime
soon. It's easier for managers to load up on cheap
bandwidth in their LANs.
Then there's Multiprotocol Label Switching (MPLS), the
ISP's dream technology for engineering the network for
QoS instead of overengineering it with capacity. MPLS
includes LDP, a protocol that sets up paths for
class-based traffic, as well as future protocols that will
handle the traffic engineering piece. MPLS is based in
part on Cisco's tag-switching technique for switching IP
traffic across ATM or frame relay WANs.
Although MPLS is at least a year away from
implementation in ISP networks-the MPLS specs won't
hit the standards track until the middle of next year-the
technology has the attention of many ISPs. With MPLS,
an ISP could designate a specific route for all Hypertext
Transfer Protocol Web traffic, much the way they do it
using ATM. But MPLS will be more dynamic, not
requiring the manual configuration of switches as ATM
does, says Steve Onishi, product line manager at Bay
Networks.
QoS Hype
Even with all the hype over QoS, some experts question
whether QoS is more a short-term fix than a long-term
architecture. WAN backbone technologies like wave
division multiplexing are emerging for ISP networks,
which could solve the congestion problem merely with
megacapacity. Wave Division Multiplexing-a
multiplexing scheme based on channels of light-extends
the capacity of a Sonet transmission network. "Are we
designing for shortages that won't exist forever?" the
International Computer Security Association's
Moskowitz asks of the QoS craze.
And just how much bandwidth can one app digest
anyway? Mindspring's Ross says, "For the foreseeable
future, QoS will be needed. But there's a convincing
argument that available [WAN] bandwidth is growing
so quickly that it may not be a problem."
For now, technologies like WDM are far from
widespread on the Internet, and the enterprise manager
just can't afford to throw bandwidth at the WAN or rely
too heavily on crash-diet approaches like
packet-shapers and bandwidth managers. So, since ISPs
want to deliver different classes of service-and every
indication is that network managers will be willing
consumers-QoS may shape up to be the standard for a
long while.
Kelly Jackson Higgins is a technology journalist based
in Stanardsville, Va. She can be reached at
kjhiggins@aol.com.
Copyright - 1998 CMP Media Inc.
By Kelly Jackson Higgins
<<INTERNETWEEK -- 09-28-98, p. PG35>>
[Copyright 1998, CMP Publications]
|
