Overhead on ADSL with PPPoA; optimising MTU

Hey all,

Ever since I came across Lawrence Baldwin's site, I've been trying to work out what the optimal max MTU for a ADSL connection with PPPoA. His site discusses PPPoE but he mentions and I think he's right he's made a few mistakes and he's given up on it.

Anyway, I've been looking into it and best as I can make out, for VC-mux the optimal highest MTU commonly supported would be 1480. AAL5 with VC-mux has a 8 byte SAR trailer at the end of the last cell and is padded if necessary. With a 1480 byte MTU, 30 of the cells with have a full 48 bytes of data, the last cell will have 40 bytes of data and the 8 byte trailer.

With SNAP/LLC, the optimal MTU should be 1472 since it adds a 8 byte header.

I think all this is correct assuming I'm right that a 1480 byte IP transmission unit means 1480 bytes through the ATM link. I'm still not clear if there is any other overhead I'm missing. Lawrence's site suggests there is ethernet overhead but I think he's wrong??? If there is a 38 byte ethernet overhead that is sent through the ADSL ATM link, then the optimal max MTU would be 1490 I think (for VC-mux)?

For PPPoE, there is another 8 bytes of overhead to consider of course...

P.S. This is only relevant if you want to get the maximum out of your modem's ADSL link. If, for example, your ISP does not give the maximum from your link but does traffic shaping later on, it doesn't really matter, in fact a max MTU of 1500 is optimal since this minimises TCP/UDP overhead.

Reply to
Nil Einne
Loading thread data ...

formatting link

Reply to

I read a bunch about the theory of optimum PPPoE MTU based on filling ATM cells. But an evening of testing from 1492 to 1400 with a stable connection that tested consistantly within 1 or 2 kbps for multiple tests at any given MTU, nothing for me beat the maximum PPPoE MTU of 1492, although, MTU 1400 was close.

This was easy to test with Linux, because its ifconfig allows easily changing its pppoe MTU on the fly. The fact that MTU actually changed was confirmed using ping with specified data size and "do not fragment" flag (max successful ping data + 28 = mtu).

Maybe my ISP doing PPPoE over L2TP throws a wrench in such ATM cell calculations. But my conclusion was that dropping my MTU from its maximum within that range did not gain me anything, and at worst was insignificantly slower. Test results may vary if you have path MTU discovery problems or other issues.

Reply to
David Efflandt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.