@Borromini asked in
about guidelines for determining the overhead in use by non-ADSL links.
At the moment I only have a relatively robust and reliable method to empirically detect the per-packet-overhead (required e.g. by sqm-scripts to properly configure the shaper) that works by exploiting the quirks of ATM/AAL5 encapsulations (effectivelt ADSL1, ADSL2, and ADSL2+). Folks with enough interest and time can look at
for instructions and code.
Unfortunately, that rather slow and tedious method relies on detecting the RTT transitions caused by ATM-call "quantization" and hence falls flat when used on non ATM/AAL5 links.
For other links currently, I can not offer an empiric method, so poking through an ISPs available information seems to be the only viable option, no matter how unsatisfactory. This together with a bit of common sense can help a lot (especially if one realizes that from the shaper's perspective it is fine if overhead is over-estimated and gross-rate is under-estimated).
Now, in theory for all links the following equation gives the relation between true gross-rate, per-packet-overhead and goodput:
gross-rate * (payload_size) / (payload_size + per-packet-overhead) = goodput
goodput, can theoretically simply be measured by e.g. an on-line speedtest, but that still leaves the two unknowns gross-rate and per-packet-overhead.
The challenge is now to use (typically relatively imprecise) goodput measurements to deduce both true gross-rate as well as per-packet-overhead. Intuitively, measuring goodput at two different payload_sizes should be enough to ultimately calculate both unknowns. And with 100% correct goodput numbers that works like a charm, but once the goodput number's accuracy differs between the two measurements this idea get murky pretty quickly, and I have not yet found a way around this (not that I have much time for looking into this).
Sorry, that this is not really giving a proper answer, but that is all I have got so far, for non-ATM links.