Re: [tor-bugs] #7009 [Tor]: Handle unstable relays better

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#7009: Handle unstable relays better
---------------------------------+------------------------------------------
 Reporter:  arma                 |          Owner:                    
     Type:  project              |         Status:  new               
 Priority:  normal               |      Milestone:  Tor: 0.2.5.x-final
Component:  Tor                  |        Version:                    
 Keywords:  tor-relay, SponsorJ  |         Parent:                    
   Points:                       |   Actualpoints:                    
---------------------------------+------------------------------------------

Comment(by arma):

 Replying to [comment:10 nickm]:
 >   * This doesn't really have much to do with dynamic IPs.

 I think that's ok, so long as we decide it's a good and useful thing to do
 for Tor.

 >   * There's a lot of space going to relays that clients mostly don't
 use.  If we realizing that if we discarded all nodes with Bandwidth=X for
 X under 100 we'd dump 48% of the nodes in the md consensus, but only about
 half of a percent of the total capacity according to Bandwidth=X.

 Sounds like #1854. I think the current direction there is that Paul et al
 have argued we should keep small relays in the consensus, even if clients
 don't use them, since this is a community and turning away half our
 volunteers simply because we don't currently need them will harm the
 community. (Also, there are future directions like path splitting that
 might be able to make use of them again.)

 I admit that I'm intrigued by the notion of having them in some form of
 the consensus but maybe not all forms.

 >   * There still isn't a good C library we can link for diff.  Otherwise,
 we could do worse than exec as needed and require a working diff on every
 Tor directory, I suppose.

 Don't the clients need a working diff program too, to combine their
 current consensus with the new update they fetched? I guess it depends on
 our design, but I always figured it would be clients who fetch diffs too.

 >   * If we don't need so much bandwidth weight granularity, we could win
 some space by dropping it.
 >   * Rounding bandwidths off helps a little, but I'm not sure what we
 lose by doing so.

 It doesn't look like the win is enough to merit trying to answer this
 question. (Or alternatively, it does look like we can make that decision
 later, and any of these diff approaches will benefit from that change
 then, yes?)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7009#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs