[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] Re: #1750 [Tor - Relay]: Project: See if we can improve performance by throttling busy streams at guard nodes
#1750: Project: See if we can improve performance by throttling busy streams at
guard nodes
-------------------------+--------------------------------------------------
Reporter: nickm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Deliverable-Sep2010
Component: Tor - Relay | Version:
Keywords: | Parent:
-------------------------+--------------------------------------------------
Comment(by arma):
So what do we expect to see in the torperf results if we set those params?
For the 5MB stats, the first 2MB come at the previous pace, but the last
3MB take a minimum of 3000/5=600 extra seconds, or 10 more minutes. That's
a serious increase over the current 5MB stats, which average 50 to 100
seconds currently.
So we should certainly expect the 5MB results to jump. But what about the
50KB and 1MB results? They could be the same, or they could become better.
It really depends how many connections there are that are sucking down
more than 2000+5n/s kilobytes, and how much spare bandwidth there is. That
is, for relays that have plenty of bandwidth to play with, we shouldn't
expect to see an improvement in 50KB or 1MB results if this is the only
relay that's doing it.
So the first observation is that for best results, we should do it on a
relay that's in the sweet spot -- not so fast that it can handle all its
users (relative to their second hop relay), and not so slow that its users
are getting throttled close to 5KB/s anyway. I'm not clear where that
sweet spot is.
The second observation is that we are expecting network effects from this
change, that can't be seen just by changing one relay. In particular, we
are hoping that the second hop and third hop will become faster too if
other relays in the network stop introducing so much congestion. So just
varying a single entry guard and leaving the rest of the network alone
won't give us the whole picture.
The third observation is that it isn't really stable long-term to leave
any given choice of parameters enabled in the consensus. What we're trying
to do is divide typical web browsing users from typical bulk-download
users (such that we punish basically none of the web browsing users), and
then we're hoping that squelching the bulk-downloading users will result
in less congestion throughout the network. Ultimately I am guessing the
params should be a function of traffic we're seeing. This question would
be a great one for some researcher to help out with. It sure would benefit
from a Tor network simulator too.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1750#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online