[AUUG-Talk]: Documenting how ADSL modems work?
andrewr at iagu.net
Thu Sep 8 17:35:03 EST 2005
At 9:58 PM -0700 7/9/05, Michael Paddon wrote:
>The ADSL link layer consists of a synchronised stream of fixed
>length frames. You may remark that this looks a lot like ATM and, indeed,
>the multiplexing layer of the ITU ADSL standard is built on ATM.
>Knowing this, a bunch of jargon begins to make sense...
The reason for this is at the time ADSL standards were being
developed, carriers thought ATM was going to take over the world,
instead of IP. It seemed logical to use ATM framing to the end device
so then no conversion would be required when routing through their
networks to the end point.
There were a lot of people who thought people would place calls over
ATM (like phone calls) and that multiple people in a house would
place multiple ATM calls simultaeneously, so a worker could be
connected to the comapny LAN while someone else was connected to a
None of this ever came off - well, not much of it, and certainly not
>Some devices claim to "auto-negotiate" VPI/VCI, but I believe that they
>simply hunt among a set of well know VPI/VCI values until they find a frame
>they recognise. In practice, expect to set the values manually to the magic
>numbers provided by your ISP.
You can also get lucky by just passively waiting - if you see a cell
arrive with a VPI/VCI tag, you can assume that's the active one and
try sending stuff back on the same VPI/VCI. ATM's UNI (User to
Network Interface) allows you to negotiate this, but only if you're
trying to do the equivalent of placing a call.
>Unspecified bit rate basically means that there is no QoS service on an ATM
ATM has a whole bunch of specified bit-rate stuff for things like
voice (regular packets per second), video (certain known minimums and
maximums), etc. "Unspecified" is everything else - the stuff
generally interesting to us.
You can get QoS with unspecified bit-rate, but it's up to the devices
to implement rather than being part of the standard.
Another thing not many people realise is from the ATM heritage. Your
1.5M service isn't really 1.5M usable - it's the old hard drive space
con all over again.
53 byte cells are on the wire, of which 48 is the payload and 5 is
the headers, means your 256k back-channel is really 231k. With a
payload size of 48 bytes set - smaller items are padded - if you want
to send a TCP ACK over PPPoE you need 14 bytes PPP, 6 bytes PPPoE, 20
bytes IP header, and 20 bytes TCP header, that's 60 bytes - or two
cells, so 106 bytes on the wire, nearly doubling the required
bandwidth - so your 256k backchannel can only send 99k of actual
TCP/IP traffic. With some TCP implementations, this can mean your
download speed is controlled by the rate at which you can send ACK's.
More information about the Talk