[geeks] DSL/PPPoE query - Am I insane?

[Greg A. Woods]

[ On Monday, April 8, 2002 at 22:30:59 (-0400), Ryn wrote: ]
> Subject: Re: [geeks] DSL/PPPoE query - Am I insane?
>
> I still disagree with the use of ATM with DSL. 5 bytes per cell is a lot
> of overhead.

That argument against ATM is as old as the hills.  UUNET/AlterNET fought
it (rather successfully in the end it seems) when they first built their
all-ATM network "years ago".  :-)

> each 1500-byte frame gets run through the ATM AAL 
> and adds about 140-bytes of overhead (in addition to IP/TCP/UDP 
> overhead). In all my DSL reading I have still not found a definative 
> answer as to why most ILECS and CLECS chose ATM as there layer 
> 2 transport protocol.

You have to realise that many carriers have very large ATM networks, and
all the requisite operations and management infrastructure to make them
work _very_ smoothly, already in place, and they use them to transit all
kinds of services, not just xDSL (eg. voice, video, frame relay based
"private" networks, etc.).  DSL services are a much more recent
after-thought.

In regions like this one here where I am where the local telco
"monopoly" provides resellers who are not also already CLECs in their
own right (and who don't have the mega-$$$ to put their own DSLAMs in
rented telco CO rack space) the ability to resell xDSL services it's
pretty much the telco alone which chooses how it will transit customer
circuits to the reseller, and they most often choose ATM.

I'm not quite so familiar with the low-end (home/SoHo, generally 1-mbit
or so downstream in these parts) PPPoE services, but at the next level
up (which happens to be what I have at home now myself), each customer's
DSL modem bridges Ethernet traffic to the DSLAM at the CO where it's
turned back into Ethernet and stuffed into a VLAN and the whole mess of
VLANs from a given group of customers to a given reseller is then
stuffed into an ATM PVC and sent to the reseller.  At the reseller's POP
the PVC is split out back to Ethernet on an ATM edge device and the
VLANs are trunked (usually over a single 100baseT/FDX connection, though
I guess if the bandwidth demanded it would be muliples with EtherChannel
or something like that) the reseller's switch/router/whatever (my
provider uses netgraph in FreeBSD to turn each VLAN into a virtual
interface, and they manage customer routes using OSPF and BGP with zebra).

> ATM would prove helpful if you were to packetize 
> voice traffic...but they aren't.

Oh, but they are, and have been for some time, at least around here!

(Of course there are some nuts trying to run VoIP through this whole
mess too, really making the overhead stink to high heaven!)

There's also the fact that once you get up into the OC3 and faster
speeds ATM is really the only currently feasible way to really tightly
manage routing, bandwidth aggregation, traffic limits, etc.  You just
cannot possibly manage a really large and complex network where you've
got dozens of different customers logical circuits running through pipes
as fat as OC192 with IP alone, esp. not with today's SLAs demanding very
exacting parameters for each and every one of those logical circuits.
The likes of Sprint and Teleglobe are offering SLAs guaranteeing 40ms
and sometimes even as low as 20ms IP latency between any two points in
North America!  Even with a herd of multi-million dollar Juniper routers
you just couldn't do that using IP alone.  ATM really is where it's at
when it comes to running highly managed virtual circuit networks.  There
have been dozens of years of very intensive research put into it from
the telco side so that packet networks can work flawlessly for demanding
realtime applications such as voice and video conferencing.  The
relatively small amount of overhead required to get this kind of
performance and managability is well worth the cost.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>