Re: secret_id_key

[Scott Bennett <bennett@xxxxxxxxxx>]

     I wrote:
>     On Tue, 14 Jul 2009 01:56:18 -0400 Roger Dingledine <arma@xxxxxxx>
>wrote:
>>On Wed, Jul 08, 2009 at 12:42:55PM +0200, Olaf Selke wrote:
>>> about three weeks ago my exit node traffic dropped from about 45 MBit/s
>>> to 10-20 MBit/s. There's no explanation regarding network connectivity
>>> or server environment. Within the last three weeks the traffic didn't
>>> recover to the former value > 40 MBit/s until I generated a new
>>> identity. With a new secret_id_key file the traffic recovered to the old
>>> value after one day.
>>> 
>>> Does anyone have an explanation for this?
>>
>>About three weeks ago we got an influx of new relays, and many of them
>>were exit relays. In particular, we got enough that Tor Exits were
>>allowed to be marked Guards again too.
>>
>>To understand what I just said, see Sec 3.3 of
>>https://git.torproject.org/checkout/tor/master/doc/spec/dir-spec.txt
>>  If the total bandwidth of active non-BadExit Exit servers is less
>>  than one third of the total bandwidth of all active servers, no Exit is
>>  listed as a Guard.
>>
>>So before mid June, relays had either Guard flags or Exit flags but
>>never both.
>>
>>My guess is that having both of those flags makes clients less willing
>>to use you as the middle hop, so your traffic drops.
>>
>>When you threw away your key, you lost your Guard flag, so the middle-hop
>>traffic returned.
>
>     Perhaps the above suggests a minor modification to the authority code,
>to wit, a node with known data rate capacity equal to or greater than x B/s
>shall be exempted from this particular requirement for assignment of a
>guard flag.  blutmagie is, and has been for a long time, among the very
>fastest nodes in the entire tor network.  It is important that the capacity
>of such nodes not go to waste.  A line in the authorities' torrc files
>could then authorize guard flags, still subject to other criteria for guards,
>for nodes exceeding, say, 2 MB/s or some other appropriate figure.  Such a
>torrc line would allow observation of its effects over time, so that the
>authority operators could fine tune the threshhold for the exemption.

     Having reread all of the above after posting my followup:-{, I now see
that it is obvious that I should also have suggested a client-code change that
would also recognize an exemption for very-high-data-rate nodes to be chosen
as middle nodes.  This would entail either hardcoding it or adding yet another
flag, I suppose.  Bummer.  The point of all of this is that the nodes that
support very high rates should be usable for entry and middle node positions
in routes at all times and also for exits if the node allows exits.  That
sort of capacity really must be kept available, not wasted.
>>
>>This is a special case of another bug I've been working on:
>>http://archives.seul.org/or/cvs/Apr-2009/msg00074.html
>>which is that the longer you've been a guard, the more clients you
>>attract, and new guards have almost no clients. That's fixed in Tor
>
>     Did the client code really look at the uptime of guards?  Or do you
>just mean that clients that have been running for a long time still have
>connections to nodes that had guard flags at the time the clients were
>initialized?
>
>>0.2.1.14-rc, but we need most people to upgrade before it matters much.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************