[Cerowrt-devel] Correctly calculating overheads on unknown connections

[Sebastian Moeller]

Hi Andy,


On Sep 22, 2014, at 12:01 , Andy Furniss <adf.lists at gmail.com> wrote:

> Sebastian Moeller wrote:
>> Hi Dave, hi Andy,
>> 
>> 
>> 
>> 
>> On Sep 20, 2014, at 19:55 , Dave Taht <dave.taht at gmail.com> wrote:
>> 
>>> We'd had a very long thread on cerowrt-devel and in the end
>>> sebastian (I think) had developed some scripts to exaustively (it
>>> took hours) derive the right encapsulation frame size on a link. I
>>> can't find the relevant link right now, ccing that list…
>> 
>> I am certainly not the first to have looked at ATM encapsulation
>> effects on DSL-links, e.g. Jesper Dangaard Brouer wrote a thesis
>> about this topic (see http://www.adsl-optimizer.dk) and together with
>> Russel Stuart (http://ace-host.stuart.id.au/russell/files/tc/tc-atm/)

	One note about Russel’s handy list of ADSL overheads, these do not include VLAN tags so all the shown combinations can be 4 byte larger if a clan tag is added, as is quite common nowadays for double- and tripple play connections. Fun fact for a rather run of the mill encapsulation with, LLC/SNAP over AAL5 with clan tbs we now have three independent methods to multiplex different “connections over the line” (and that does not count PPPoE), all provisioned out of the bandwidth the end user pays for and best case is only one of the is functional, but I digress...


>> I believe they taught the linux kernel about how to account for
>> encapsulation. What you need to tell the kernel is whether or not you
>> have ATM encapsulation (ATM is weird in that each ip Packet gets
>> chopped into 48 byte cells, with the last partially full cell padded)
>> and the per packet overhead on your link. You can either get this
>> information from your ISP and/or from the DSL-modem’s information
>> page, but both are not guaranteed to be available/useful. So I set
>> out to empirically deduce this information from measurements on my
>> own link. I naively started out with using ICMP echo requests as
>> probes (as I easily could generate probe packets with different sizes
>> with the linux/macosx ping binary), as it turned out, this works well
>> enough, at least for relatively slow ADSL-links. So ping_sweeper6.sh
>> (attached) is the program I use (on an otherwise idle link, typically
>> over night) to collect ~1000 repetitions of time stamped ping packets
>> spanning two (potential) ATM cells. I then use
>> tc_stab_parameter_guide.m (a matlab/octave program) to read in the
>> output of the ping_sweeper script and process the data. In short if
>> the link runs ATM encapsulation the plot of the data needs to look
>> like a stair with 48 byte step width, if it is just smoothly
>> increasing the carrier is not ATM. For ATM links and only ATM links,
>> the script also tries to figure out the per packet overhead which
>> always worked well for me. (My home-link got recently a silent
>> upgrade where the encapsulation changed from 40 bytes to 44 bytes
>> (probably due to the introduction of VLAN tags), which caused some
>> disturbances in link capacity measurements I was running at the time;
>> so I ran my code again and lo and behold the overhead had increased,
>> which caused the issues with the measurements, as after taking the
>> real overhead into account the disturbances went away, but I guess I
>> digress ;) )
> 
> Sounds like a handy script, though I am not so sure it would help for
> vdsl 64/65 (if that is actually used!).

	No, currently my script will tell you whether you have ATM cell encapsulation on your link or not (as far as I know VDSL2 means PTM (64/65), ADSL[1,2,2+] means ATM, not sure about VDSL1, but I think neither is VDSL2 prohibited from using ATM nor is ADSL stuck on ATM). If, and only if ATM is used will the script help to deduce the per packet overhead. I am still waiting for the upgrade to VDSL2 on my home link, once I have that available I will see whether I can figure out information about the per packet overhead or not; all I know is that my current approach will not work, because it relies on the ATM quantization.


> I don't think there is any
> padding (but may be wrong!).

	No, according to the standard the 64/64 encapsulation is “continous”, so not padded-out or reset for each packet

> 
> As for the history, Yea Jesper got his stuff in - but didn't allow
> negative overheads so I still used to have to patch tc to workaround that.

	True, but the “stab” work for tc got this right. Also note that the stab option does not automatically include the known overhead to the packet as indicated by the outdated man-page, so that the ability to specify negative overheads is basically not needed or useful. And yes the kernel needs to be fixed, one of these days. Speaking of kernel code, Jesper “recently” hoisted HTB’s link layer adjustment method into the present (getting basically rid of the tables and allowing for GRO packets), something that stab also needs to have fixed...

> 
> Before his work there was some user space code by IIRC Dan Singletary
> which I used for a while and later Ed Wildgoose analysed the kernel code
> and posted patches for htb and tc on the original lartc list which I
> used for some time before Jespers code got in.

	Interting piece of history, all that happened before I cared, heck even Jespers thesis was out by then.


Best Regards
	Sebastian

> 
>