ADSL overhead

Yesterday I’ve described the difference between line rate and bit rate (actually physical layer gross bit rate and physical layer net bit rate). Going to the other extreme, we can measure goodput (application-level throughput), which obviously depends on multiple factors, including the TCP window sizes and end-to-end delays. There are numerous tools to test the goodput from/to various locations throughout the world ( worked quite nicely for me) and you’ll soon discover that the goodput on your DSL line differs significantly from what the ISP is advertising.

Apart from obvious marketing ploys, the difference arises due to the baroque Russian dolls encapsulation stack used on ADSL (see the ADSL-based protocol stacks section in this document). A typical PPPoE connection runs IP over PPP (2 bytes) over PPPoE framing (6 bytes) over Ethernet framing (14 bytes) over RFC 1483 bridged connection (8 bytes) over AAL5 (8 bytes) over ATM cells (5 byte overhead for every 48 bytes of payload). Every IP packet is thus burdened with 38 bytes of DSL protocol stack overhead plus 10.4% ATM cell tax. Assuming the average IP packet size in the Internet is around 500 bytes, the DSL protocol stack overhead is 6%, resulting in a total of over 16% of lost bandwidth just to accommodate the committees that constructed this monster.

Update @ 2009-03-27: I forgot yet another encapsulation technique: AAL5. I also need to investigate whether the RFC 1483 bridged encapsulation really uses the 8-byte header (there are numerous options in the RFC).


  1. I am amazed to understand why windows vista is not able to get the upload and download speed more than 2 Mbps. I made all the changes but no effect. Everytime speedguide shows the same output.

    shivlu jain

  2. You need a server with fast uplink that is close to you. Testing with a far-away server will always result in low throughput due to Bandwidth-delay product.

  3. It's for this reason that the best MTU to use for an ADSL connection is 1454 over PPPoE, and 1462 over PPPoA.

    Further improvements can be made by tweaking RWIN, though good for a predictable VPN environment, this is fairly useless over the internet, as ideal RWIN value varies greatly, depending on the latency to the host you're receiving from, their upstream, and your provider's upstream, which is likely to be contended at least some of the time.

  4. @Anonymous: Somehow my calculations of total overhead disagree with the link you've quoted by 4 bytes (so my "ideal" MTU is 1450 for PPPoE).

    Anyhow, the differences are negligible. The ratio between "goodput" (application data) and raw bits on the wire is 85.82% for "optimal" MTU and 85,61% for MTU=1492.

    Also note that a lot of packets are 40 bytes long (TCP ACK), where the overhead is a whooping 62,6%, so the debate about the "optimal" MTU is somewhat academic.

  5. I think in a typical PPPoE ADSL connection we don't use RFC1483 bridging, but we use AAL5 SNAP encapsulation (also specified in RFC1483) with 8-byte header and 8-byte trailer. There is also a variable padding. I found this information here:

    Measuring the Utilization of ATM PVCs

  6. Hmmm ... time to find someone with a protocol analyser ...

  7. Hello
    we here use business class ADSL link with RFC1483 protocol... directly routed links without any ppp negotiations.
    We assume having zero overhead then?

  8. Ivan Pepelnjak30 July, 2010 17:20

    You still have to deal with RFC1483 encapsulation, AAL5 encapsulation and ATM cell tax (5 bytes of overhead in each 48-byte cell + some unused space in the last cell of the packet). Here's a good explanation of what you have:


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354 Emeritus, is an independent network architect. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.