> On 3 Sep 2016, at 05:55, grarpamp <grarpamp@xxxxxxxxx> wrote: > > On Fri, Sep 2, 2016 at 7:30 AM, Michael Armbruster <tor@xxxxxxxxxxx> wrote: >> On 2016-09-02 at 13:18, jensm1 wrote: >>> which shows that the advertised relay bandwidth in the whole network is >>> more than double the actually used bandwidth. While it's certainly nice >>> to have a bit of breathing space to absorb load spikes, I'm wondering, > >> it's always good to have even more relays or exit nodes, as more "hop >> points" for connections means more diversity throughout the network > > Once a net reaches adequate bandwidth capacity, adding more > nodes can do a few things among others... > Good: > - Gives operators deployment experience till their bw is needed, at $cost. > - More non-evil relays gives better odds of building a non-evil path, but tor > weight's things so not exactly. > - May add some capacity for directory operations etc > Bad: > - Yields rather unused nodes making it easier for passive > observer to see you tack up and use a path through them, > especially if you're crafting paths. > > One key here is probably that we don't have a good idea as to the > quantity of evil nodes, or the hard interest and real capabilities of PA's. > > To make the call you'd need that, and perf metrics of your net under > different ratios of advertised:consumed:nodecount, and min/avg/max/stddev > of idle/random/full paths, to find any sweet spots / ranges. > > Also considerations of impact adding nodes of less bandwidth or > more latency than average, versus a campaign to fund replace them. > > At 42% util by one metric, it may be money and time better spent > elsewhere, even on better qualifying the default 'more nodes good' idea. There are also latency and contention considerations: an network that runs at 40% capacity has much better latency properties than one at 90% capacity. Also, in the Tor network, as soon as cells are dropped due to any relay being over capacity, this adds a significant delay, because of how Tor retransmits along the entire path, not just the busy relay's hop. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays