Re: [Cake] More overhead keywords

[Sebastian Moeller <moeller0@gmx.de>]

Hi Jonathan,

On May 18, 2015, at 10:13 , Jonathan Morton <chromatix99@gmail.com> wrote:

> Hmm. Looks like that document I found was really out of date, then. But it got me fairly close.
> 
> 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.
> 
> 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?

	Not as far as I know, but I do not claim to be an expert here.

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

	That is what I had thought as well, before realizing my ISP actually throttles my connection at the BRAS so that the VDSL link itself never becomes the bottleneck…

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

	I am not sure that wielding term as vcmix and llcsnap reduces confusion ;) just kidding.

> Second, you might underestimate the number of ADSL ISPs worldwide, as well as the difficulty of keeping such a database up to date.

	Fair enough.

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

	Well ,not in Germany were it is all detective work and no clear documentation from the ISPs.

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

	True

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

	I happen to have a very hacky implementation of such a tool available, but that only works for ATM carriers, I  am not sure whether this really can be done for VDSL2 at all (for example, some ISPs limit the number of packets per second so one never can saturate the link with small packets). But for ATM it just takes a few hours of collecting data and a bit of processing ;) 

> 
> And if the user really can't work it out, they can always throw up their hands and specify "conservative".
> 
> - Jonathan Morton