Yawning Angel yawning@schwanenlied.me writes:
On Thu, 1 Jan 2015 14:19:08 +1100 teor teor2345@gmail.com wrote:
On 1 Jan 2015, at 07:39 , Greg Troxel gdt-0NXpHMFAxfDQT0dZR+AlfA@public.gmane.org wrote:
Tor 0.2.6.2-alpha (just in the process of being released) has some changes to queuing behaviour using the KIST algorithm.
The KIST algorithm keeps the queues inside tor, and makes prioritisation decisions from there, rather than writing as much as possible to the OS TCP queues. I'm not sure how functional it is on *BSDs, but Nick Mathewson should be able to comment on that. (I've cc'd tor-dev and Nick.)
I don't think we merged that branch yet, since it's not ready for general use. Additionally, it's not currently functional on the *BSDs. The KIST code last I checked only is used under Linux. While the full portability story is in #12890 it looks roughly like:
- Linux - Supported.
- Windows - Possible, needs code in tor.
- Darwin - Possible, uses interfaces marked as undocumented/internal.
- FreeBSD - Requires a trivial kernel patch (interface is there, information exposed is incomplete).
- Other BSDs - Requires a kernel patch, which is more involved than the FreeBSD one (implementing the required interface vs exposing more information). The patch is still trivial for anyone that's familiar with the TCP/IP code.
I don't think we should be in the business of maintaining kernel patches either, so I'm not sure what the right thing to do would be for non-Darwin *BSD.
I think it makes sense to get these patches into the various systems. To ease that, it would be good to have an (experimental track, perhaps) RFC or i-d or the equivalent with the rules for the mechanism and the API specs. That both makes it easier for people and makes it more likely that the new mechanism is not a moving target.