Revisiting overhead calculation on UK FTTC connections

Alan Goodman <[email protected]> Mon, 05 Aug 2019 11:29:43 +0000
Newsgroups org.kernel.vger.lartc
Message-ID <[email protected]>
Hi All,

We had some discussion on here relating to rate estimation on ATM based 
connections and later FTTC connections back around 2014 time.

Recently I ran into some performance issues with rp-pppoe running in 
user mode that did not appear to be related to running out of resources 
on the host machine.  It seemed to be some kind of timing related issue 
and the fix effectively seems to be running rp-pppoe in kernel mode.

I am trialling this on just my home connection for the time being to 
ensure it works as reliably as the usermode variant however I ran into 
some strangeness relating to the traffic shaping / QoS after enabling 
the kernel mode operation.  Specifically fq_codel is reporting maxpacket 
higher than MTU - impossible!

With usermode PPP I run overhead 40 on upload and overhead 26 on 
download.  This seems to work well for FTTC and ADSL (BT, with linklayer 
atm for ADSL).  Max packet tends to show 1492 and shaping works as expected.

In kernel mode PPP if I run the above overhead numbers my maxpacket 
shows as 40 bytes above MTU on upload and 26 bytes above MTU on download 
(based on some very unscientific testing earlier).  In kernel mode I am 
finding that omitting stab overhead on upload works best and on download 
I am finding that -14 works well on download (to work around the kernel 
adding 14 bytes for ethernet overhead twice).

With the above stuff in mind, I think it is worth me revisiting you 
folks to find what the current best practice for calculating and 
implementing these overheads is?  Does running kernel mode pppoe impact 
this decision at all?

My test connection is BT Business Infinity FTTC/VDSL.  I'm running 
CentOS 7 with the current Plus kernel.  HFSC+FQ_Codel with stab as 
described above.  PPPoE with BT Hub 5 modem in bridge mode and VLAN 
Tagged uplink to the rest of the network.

Alan