2

I just installed SQM QoS on my Linksys E4200 (V2) in order to fix some, frankly, horrendous bufferbloat. This seems to have fixed the issue, however, it has now introduced bad packet loss that wasn't there before.

P.S - make any replies easy for a networking noob to understand, I only know the basics :)

Climatee
  • 21
  • 1
  • The first question to ask would be how are you measuring your packet loss? Packet loss is perfectly normal on a saturated connection. It is sort of the opposite of bufferbloat. In fact, packet loss is required for TCP to properly adjust the transmission rate and prevent bufferbloat as you have said. Bufferbloat is caused by over zealous buffering of packets in a frivolous attempt at *preventing* packet loss while at the same time breaking the TCP protocol’s own flow control mechanisms. So again, how are you testing for packet loss and what impact are you seeing from it? – Appleoddity Jan 06 '20 at 05:23
  • Please edit your original question to include how you're measuring packet loss, what levels of packet loss you've measured (especially as a percentage of total packets), and how the measurements differ with SQM on vs off. It would also be good to know how throughput and latency changed too, so we can see if the packet loss you've detected is having a negative or positive impact on throughput and latency. – Spiff Jan 06 '20 at 08:20

1 Answers1

1

Packet loss is normal for a congested link and it functions as the most widely recognized signal of congestion. SQM judiciously employs smart early packet loss in order to let the machines sending and receiving TCP streams detect the congestion so that their congestion control algorithms can kick in. Bufferbloat was caused by designers of networking hardware (wrongly) thinking all packet loss was bad and trying to avoid packet loss at all costs.

Today there is a TCP/IP protocol enhancement called Explicit Congestion Notification (ECN) that allows networking hardware to explicitly notify devices that a link is congested, without resorting to the age-old method of dropping packets to signal that congestion is happening. All modern OSes support ECN, but not all have it enabled for all connections by default. If you enable ECN on all your devices' TCP/IP stacks (and the TCP/IP stacks of all the other servers/peers/hosts they talk to on the Internet), then your SQM-capable networking equipment will be able to use ECN flagging on those connections instead of resorting to the old tried-and-true method of dropping packets to signal congestion.

The way to enable ECN varies from OS to OS, but for Unix-like OSes it generally involves using sysctl.

See https://www.bufferbloat.net/projects/cerowrt/wiki/Enable_ECN/

Spiff
  • 101,729
  • 17
  • 175
  • 229