https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289333
Bug ID: 289333
Summary: [Feature Request] HFSC overhead calculation
Product: Base System
Version: Unspecified
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Please add a constant per-packet overhead factor to HFSC packet length
calculations. (This could probably be abstracted to other ALTQ structures, but
I only know HFSC.)
I use FreeBSD HFSC on a relatively low-bandwidth DSL connection (15000 kbps
down, 800 kbps up). My modem's PPPoE encapsulation adds 28 bytes of overhead
per packet (MTU = 1472 instead of 1500). I mainly need to prioritize uplink
bandwidth for VOIP.
If VOIP only had to contend with large packets -- such as file uploading -- the
overhead calculation would be fairly straightforward. I would just set my WAN
interface limit around 95% of the actual modem link rate; standard
configuration practice recommends this anyway.
However, the asymmetric link creates problems... It is not uncommon to see 300
- 400 kbps worth of ACK traffic on the uplink during heavy downloading
conditions. At least, that's what FreeBSD _thinks_ it's sending to my WAN
interface. In reality, those small ACK packets can consume up to 600 kbps of
my actual DSL modem bandwidth. And when combined with other upload traffic
such as VOIP, the modem has to start dropping packets.
Currently, I have to set my HFSC limits around 70% (550 kbps) of my actual
uplink bandwidth to avoid dropped packets. With the link as slow as it is in
the first place, that hurts.
Using an overhead factor in the HFSC calculation would allow HFSC to make
better use of the available bandwidth. Obviously I can't change the actual
size or overhead when the ACKs congest the uplink. But, I would be able to use
a much larger percentage of the link "large packet" activities such as backups.
I have reviewed hfsc_enqueue() in altq_hfsc.c and see the calculation of packet
length derives directly from m_pktlen(m), so I don't think this request
duplicates any existing features.
PS: I think this request is comparable to the Linux "Overhead Compensation"
feature in CAKE.
--
You are receiving this mail because:
You are the assignee for the bug.
