[tor-relays] total relay bandwidth

[teor]

> On 3 Sep 2016, at 05:55, grarpamp <grarpamp at gmail.com> wrote:
> 
> On Fri, Sep 2, 2016 at 7:30 AM, Michael Armbruster <tor at armbrust.me> 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






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160903/d1990703/attachment.sig>