[AUUG-Talk]: Documenting how ADSL modems work?

[Andrew Rutherford]

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 
random ISP.

None of this ever came off - well, not much of it, and certainly not 
in Australia.

>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
>circuit.

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. 
:-(