<p dir="ltr">Hmm. Looks like that document I found was really out of date, then. But it got me fairly close.</p>
<p dir="ltr">For me, the overhead starts at the IP packet (so for your example, at the 1492 byte level), and excludes optional parts of the spec like FCS (since I have a separate flag for that). So I need to take the 8 bytes for PPPoE, the 14 for Ethernet and the 4 for PTM, total 26 - one less than my existing figure.</p>
<p dir="ltr">Presumably the bridged version is also one byte smaller than my calculation, 18 rather than 19. Is there also a version which transmits IP without Ethernet framing?</p>
<p dir="ltr">You would then specify "pppoe-ptm ether-vlan via-ethernet" to set your example connection up the friendly way, or just "overhead 16" for the terse way (and you can already do that in the current version).</p>
<p dir="ltr">The 64/65 sync overhead is something we'll have to discover by experiment. Luckily, it's pretty easy to tell whether we're filling up a dumb FIFO or not.</p>
<p dir="ltr">I've gone for the technical labels for three reasons. First, it reflects what's actually happening, which generally reduces confusion in the long run. Second, you might underestimate the number of ADSL ISPs worldwide, as well as the difficulty of keeping such a database up to date. Third, every DSL modem and ISP I know of has made it reasonably easy to discover at least the base encapsulations - autodetection of vcmux vs llc isn't absolutely reliable, for example. They might be less forthcoming about vlan and FCS, but one can make intelligent guesses here, based on whether it's a converged services ISP.</p>
<p dir="ltr">Ideally, we could do with a tool (at dslreports?) which makes detecting the actual overhead easier. This would be doable using small packets to magnify the differences.</p>
<p dir="ltr">And if the user really can't work it out, they can always throw up their hands and specify "conservative".</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>