[Bug 289333] [Feature Request] HFSC overhead calculation

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289333

--- Comment #4 from Daniel Engel <freebsd@danielengel.com> ---
(In reply to Oleksandr Kryvulia from comment #3)
I don't think this configuration would address the problem at all.  

I'll leave aside the potential 'burst' issue with bufferbloat for now, since I
don't actually know how big of a buffer my modem has internally.  

The main problem is that not all 700 kbps traffic flows are created equal. 
Consider the range of TCP/IP packet sizes: 

* Large packet case (e.g. file upload):
  58 pkt/s * 1492 bytes/pkt * 8 = 692288 kbps (dummynet output)
  58 pkt/s * (1492+38) bytes/pkt * (53/48) * 8 = 783870 kbps (modem output)

* Small packet case (e.g. ACK): 
  2187 pkt/s * 40 bytes/pkt = 699840 kbps (dummynet output)
  2187 pkt/s * (40+38) bytes/pkt * (53/48) * 8 = 1506843 kbps (modem output)

In the latter case, the modem would have to drop almost 50% of packets even
though dummynet is shaping the link to the same throughput in both cases. 

NOTE 1: I'm not 100% sure on the specific framing differences between ADSL and
ADSL2, or exactly what layers are present on my ADSL2 connection.  I'm basing
my calculations on the summary linked below.  It seems consistent with my
real-world experience:  

https://blog.ipspace.net/2009/03/adsl-overhead/

NOTE 2: Throughput for ACKs is even worse than the calculation above.  ATM will
add padding if necessary to fill out the last cell.  So, a 78 byte ACK(20 TCP +
20 IP + 38 ADSL) actually wastes  an additional 18 bytes to fill out 2 ATM
frames before encoding (106 bytes on the wire).  

Regarding "stateless rules", I use PFsense floating rules and haven't seen any
issues with queuing inbound or outbound traffic correctly.

-- 
You are receiving this mail because:
You are the assignee for the bug.