After reading Jim Gettys investigations about the problems current buffer sizes of network equipment provoke (which may even have implications in the net neutrality debate), I had a look at which active queue management (AQM) algorithms with or without explicit congestion notification (ECN) FreeBSD supports.
It looks like there is not much implemented (if the best solution would be implemented, it would not matter how much there is, but unfortunately there is no best solution). Other systems offer more. RED is implemented, but even the inventor/researcher of RED thinks the algorithm needs some improvements (he is in the process of preparing a paper about this, as Jim Gettys reveals). Blue/SFBlue is not implemented (a more turnkey-solution than the current RED implementation). PID controller (which may or may not be something someone wants to use in this case… no idea about its pros/cons in this regard, but it is referenced in the AQM article on Wikipedia) is also not implemented.
Regarding ECN for FreeBSD you can find more or less no real documentation in the net (at least with a simple “ECN FreeBSD” search). It is implemented for the RED algorithm, but as the RED algorithm needs some tuning/setup, this is not a turnkey solution. There is a ECN related sysctl, but I do not have the impression that this is a turnkey-solution which magically generates ECN messages without using dummynet for AQM.
From my current understanding (but I think I do not know a lot about this topic) it looks like AQM is a feature most people would like to have activated by default (with an appropriate algorithm which does not need tuning to produce a good enough result). If this is correct, it is a shame that FreeBSD does not activate AQM with an algorithm which is not bad for most cases by default (with the option to change the algorithm and to disable completely). If my understanding is not correct, I would like to get a hit with the clue bat please.
Altq has implementation of these AQM.
But the issue is still the same it does not play well with multiqueue.
You are confusing router ECN with host ECN. Host ECN is what I implemented and it works fine. Router ECN is available with RED on ALTQ.
So the sysctl is host ECN, and the altq part is router ECN? If yes, what prevents us from enabling host ECN by default (what are the drawbacks), either by switching the sysctl or via a rc.conf setting? I am aware that no rc.conf support exists yet, but IMO this would be easy to write.
What is the difference between host ECN and router ECN? For me (with just the Wikipedia-knowledge about ECN) it looks like in both cases a system should look if any buffer involved passed a specific fill-level and then send a ECN message. I can understand that different AQM algorithms may want to modify the ECN trigger level/behavior, so it is maybe a little bit more complicated, but from a big picture view I assume this is what is happening and I do not see a difference between host and router behavior.
Can someome please shed some light on it. An URL would be sufficient.
The router only marks the ECN packets
The hosts setup ECN between themselves and they are responsible for throttling the tcp window down when they see marked packets.
No one turns ECN by default because middleboxes don’t understand the new option and will reject ECN packets.
What is the impact of rejected ECN packets?
Connections take longer to establish because the middle boxes will drop ECN SYN packets. On FreeBSD we stop using ECN after the third SYN retransmission, but if we are loading a webpage with 100 images it will take a lot longer.