Re: [tor-bugs] #2550 [Torflow]: bwauth should reschedule quicker bandwidth test when bandwidthrate changes?

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#2550: bwauth should reschedule quicker bandwidth test when bandwidthrate changes?
-------------------------+--------------------------------------------------
 Reporter:  arma         |          Owner:  mikeperry
     Type:  enhancement  |         Status:  new      
 Priority:  normal       |      Milestone:           
Component:  Torflow      |        Version:           
 Keywords:               |         Parent:           
   Points:  ?            |   Actualpoints:           
-------------------------+--------------------------------------------------

Comment(by mikeperry):

 Replying to [comment:12 rransom]:
 > Replying to [comment:9 mikeperry]:
 > > Replying to [comment:8 arma]:
 >
 > > > So in my option 2, if the relay moves from 1000MB-but-we'd
 -advertise-3000MB to 100KB, then we advertise 300KB. It's quite a hack I
 admit.
 > >
 > > Yes. Because we're dealing with ratios here internally, this is
 already what happens :)
 >
 > So if I run a few exits that advertise 20kiB/s but actually push traffic
 at 150MiB/s, and then I make them start advertising 1000MiB/s, how much of
 the Tor network's exit traffic can I sniff?

 In both cases (before and after these changes) there will be a period of
 time where you capture a ton of traffic. Now, the bw authorities already
 cap each node instance to a max of 5% of the total network capacity, so
 there is a ceiling on how much you can capture this way, even for a period
 of time.

 Before these changes, the period of time that you'd attract traffic is
 arbitrary, with a range of 0-5 days.

 With these improvements, if we're using the minimum and we schedule a re-
 measurement when we notice the new minimum of 1000MiB, it is likely that
 clients have not started using you yet, so we'd still measure you as fast
 until we decide to measure you again. Right now, there is no plan to
 schedule this sooner, so it would probably be until the entire network was
 scanned and we started again. When we implement feedback (#1976), we can
 try to think about how to better handle this re-measurement period. But
 I'm not sure exactly how to detect this.

 However, also realize the bw auths are not meant to be a strong defence
 against lying or gaming, so there are other attacks here, too. They are
 primarily a performance tool, with only minimal defences against gaming.
 For stronger defence against lying/gaming, we'd need something like
 EigenSpeed, but EigenSpeed has the exact opposite characteristics. It is
 very good against liars and gamers (compared to the bw auths, at least),
 but it sucks when it comes to properly measuring the higher capacity
 nodes:
 http://www.usenix.org/event/iptps09/tech/full_papers/snader/snader.pdf

 Nikita supposedly has some grad students looking at either improving
 EigenSpeed's high-end measurement properties, and/or combining it with
 active measurements.. The status of this is unknown, though.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2550#comment:13>
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