[tor-dev] Tor BSD underperformance (was [Tor-BSD] Recognizing Randomness Exhaustion)

[Greg Troxel]

Yawning Angel <yawning at schwanenlied.me> writes:

> On Thu, 1 Jan 2015 14:19:08 +1100
> teor <teor2345 at gmail.com> wrote:
>> On 1 Jan 2015, at 07:39 , Greg Troxel <gdt-0NXpHMFAxfDQT0dZR+AlfA at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150105/0e43b66b/attachment.sig>