Packet Tax Myths and Truths

Posted: 01/2000

Packet Tax Myths and Truths
By Charlotte Wolter

Every time an ATM network transmits data, it does so in a 53-byte packet
called a cell, which includes a five-byte header of routing and payload
information. Those five small bytes, the "ATM tax" as its detractors
(mostly Internet protocol [IP] partisans) term it, have achieved almost the
notoriety of the marriage tax. This, although it puts ATM in just the 9.4
percent tax bracket.

Wait a minute, counter ATM loyalists, IP packets have headers of about 40
bytes, and their payloads can be as small as just another 40 bytes, putting them
in the 50 percent tax bracket. The IP brigades reply that IP packets can be
hundreds of bytes long, and the payload levy shrinks accordingly.

The two sides have been sniping across the protocol barricades for years,
each hoisting the flag for the superior efficiency of its technology and the
small size of its overhead.

Now, for the first time, the organizations that represent the combatants–the
Internet Engineering Task Force (IETF) (www.ietf.org) for IP and the ATM Forum (www.atmforum.com)–are
coming to the negotiating table, literally, forming a working group to address
internetworking issues between the two standards. The ATM/IP Collaboration
Working Group, which was announced at the IETF’s September 1999 meeting in
Bangkok, will focus on formalizing how real-world network operators really use
IP and ATM, which is together rather than in competition. IP over ATM represents
as much as 80 percent of IP transport, according to industry experts.

Packet Fish Stories

How long is a packet? And how much of a packet is overhead? These questions
are not easily answered, even in the rigorously defined world of ATM. Packet
lengths can vary considerably in IP and overhead can vary in ATM.

Like the proverbial fish story, they can just keep getting bigger. Both
technologies, however, do contribute significant overhead.

ATM has a uniform packet length of 53 bytes, of which five bytes is a header
that contains routing information and a description of the contents of the
packet. The ATM packet length was chosen as a compromise when the standard was
developed: short enough to be switched very rapidly in hardware but long enough
so the overhead was not onerous.

In certain circumstances, an ATM packet can use additional bytes for other
header-type information, such as ATM adaptation layer (AAL) information. AALs
modify ATM transmission. AAL1 is for constant-bit-rate (CBR) transmission, while
AAL2 is for variable bit rate (VBR), which is the highest quality. AAL2 can add
another three bytes of call information when used for voice (see chart, below).
In IP, one of the difficulties in specifying overheads is that the size of
packets will vary by data type. ATM is rigidly set up as 53 bytes per packet no
matter what. The difficulty comes with video in IP over ATM, especially two-way
video for videoconferencing. Short packages are needed because videoconferencing
is as intolerant of delay as voice. The combination of IP protocols and ATM in
every packet produces horrendous overhead.

A recent ATM Forum "fix" has been helpful. In IP, much of the
overhead is needed because IP is connectionless. Each packet of the video has to
reintroduce itself to the network and say where it’s going. The ATM Forum
modification provides a means to transmit the IP headers just once, then use a
three-byte label on the following packets that says the information is the same.

Myth No. 1: It’s IP vs. ATM

For two warring protocols, IP and ATM spend a lot of time together, usually
as IP packets encapsulated in ATM. In fact, as much as 80 percent of IP
transmissions are encapsulated in ATM cells, according to ATM Forum estimates,
especially in WAN transmissions where there is converged traffic (voice and
data, and sometimes video) and even when the traffic is data alone.

The reason the two are so closely joined is because the two networks have
different, and complementary, strengths. ATM is designed to maintain QoS without
compromise. Its small packets, fast switching and numerous safeguards on traffic
flow prevent packet loss and delay. It requires great processing power, which
comes at a cost. IP allows delay and even packet loss, but uses redundancy and
multiple paths to make sure the message eventually gets through.

Conor Clancy, product manager, AN 2100 Gateway Exchange, Tellabs Inc. (www.tellabs.com),
describes the differences between the two networks in this way: "ATM is
more like a train with each packet following the other. IP packets are like
missiles launched on the network. IP deals with [packet loss and delay] by
sending out multiple copies." That creates a great deal of overhead, he
acknowledges, "but bandwidth is cheap on IP."

Myth No. 2: Overhead Equals Poor QoS

Although some can live with overhead, voice transmissions often are
compressed, as are headers. With IP voice, it is possible to compress a standard
64kbps-voice channel to 16kbps with little loss in quality. Adding the IP
headers brings the stream back up to about 80kbps, Clancy says. Saving bandwidth
this way "might be an issue in access networks with fixed pipes, but not in
the core," he adds.

Overhead in IP and/or ATM may be putting extra coins in backbone network
operators’ pockets, but it is less of a factor in how a network performs with
respect to QoS. "We don’t see overhead as the issue," Clancy says.
"If you think logically, IP does not work because a router has no concept
of a circuit or what the data is. And that is the reason it is so hard to get
quality of service."

Together Again: IP and ATM

Encapsulating IP in ATM involves splitting the often-larger IP packets so
they fit in the uniform 48-byte payload of an ATM packet. The protocol overhead
of the IP packet, about 40 bytes, is retained and another five bytes per packet
of ATM overhead are added.

This does not make IP over ATM the most bandwidth-efficient transport
mechanism in networking. "If you take packetized voice and put it in an ATM
cell, then you have the worst of both worlds. IP has a lot more overhead than
ATM does. If you look at a header, there are only five bytes in ATM and 40 in
IP," says Ray Keneipp, director, internetworking service, The Burton Group
consulting firm (www.tbg.com). "But people
don’t look at it that way, because all the applications are running IP, so you
have to have IP."

That the two protocols are so married is largely a result of the differences
between corporate networks and WANS. Enterprise networks are Ethernet, which is
carrying all IP data traffic. As this traffic moves across cities and across the
country, it comes onto ATM networks designed to carry a combination of this data
and voice for long distances with high QoS. IP traffic is encapsulated in ATM
for these existing networks.

This will continue even as enterprises begin to move voice onto LANs as IP
voice, Keneipp says. "If you are building a [carrier] network today, you do
it with ATM in the backbone. You would packet-ize the voice in IP [and] then put
it inside ATM cells, because, right now, there are no quality-of-service
capabilities in the IP world. [To get QoS] in IP, you could go into your network
and tweak all of the queuing buffers and the routers, but usually in the IP
world you are transporting across more than one network, not just yours. With
ATM, traffic can go from network to network, and there are rules for
transporting. That is an important difference."

Fred Baker, area director, General Area, IETF, maintains that "given the
respective growth rates of data traffic and voice traffic, there will be [no]
business case for running separate voice and data networks a decade from now. A
lot of telcos are seriously asking that question, as is the ITU (International
Telecommunications Union, www.itu.org)."

Efforts to take ATM to desktops have largely failed because of the cost of
ATM interfaces for PCs. Many applications within an enterprise use IP, further
strengthening its grip on corporate nets. Therefore, enterprise networks likely
are to remain IP, while MANs and WANs are likely to remain ATM. However, traffic
usually will be encapsulated in ATM as soon as it leaves an enterprise.

So customers live with the overhead, and service providers accommodate it
(and collect the extra revenue), because the system works, and because
bandwidth, for the time being, is cheap.

Finding a Fix

Will the two go their separate ways? Not in the near term, say experts,
because ATM still is perceived by those in telecommunications as being required
for QoS across WANs. "The only way to get pin-drop quality is ATM,"
says Clancy, whose company, Tellabs, has sold ATM equipment to Sprint Corp. (www.sprint.com)

What may happen in the long run is that IP may acquire enough QoS
capabilities to replace ATM gradually in these environments, though the timing
and exactly how this would play out are murky. Extensive efforts are under way,
especially with multiprotocol label switching (MPLS) in carrier networks, to add
QoS. "A lot of money is being thrown at the problem," Clancy says.
"There certainly will be IP in access networks."

The IP/ATM Collaboration Working Group is focusing on the preponderance of IP
over ATM and how to make those networks function more efficiently. "There
was a transition period six to nine months ago, when someone looked at how much
of that stuff being sold or how much IP over ATM there was," says Rick
Townsend, chairman, technical committee, ATM Forum, and distinguished member of
technical staff, Lucent Technologies Inc. (www.lucent.com). "At some point
[in networks] someone is paying the bill, and telcos feel they can live with IP
over ATM." In addition, he says, telcos will want to use IP for voice at
some point, "though it’s not there yet."

Some are predicting that the two protocols might be combined. Fred Harris,
director, network planning and design for Sprint, has suggested that what is now
IP could add some ATM features for QoS, but this would be a longer-term
development, five years or more in the future.

Typical Overhead Penalty For Voice: IP and ATM

Charlotte Wolter is infrastructure editor for PHONE+
magazine.