[tor-bugs] #25687 [Core Tor/Tor]: extreme over-report of observed / self-measure bandwidth on fast hardware -- critical to torflow / peerflow
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Apr 2 11:07:51 UTC 2018
#25687: extreme over-report of observed / self-measure bandwidth on fast hardware
-- critical to torflow / peerflow
--------------------------+------------------------------------
Reporter: starlight | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor: unspecified
Component: Core Tor/Tor | Version: Tor: 0.3.3.3-alpha
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------+------------------------------------
Changes (by starlight):
* version: => Tor: 0.3.3.3-alpha
Comment:
In my view the problem constitutes a critical measurement error. The most
important consumer of this value is `torflow` and overstating true
available bandwidth distorts consensus allocations. No chance
overstatements are correct, especially in the traffic-control scenario
where Linux caps bandwidth with fine-grained, reliable precision. Some
ISPs permit traffic to burst briefly before enforcing bandwidth
restrictions, but in the cases I've seen bandwidth self-measure is well in
excess of the the line burst rate and anyway reporting burst-rate maximum
capacity to torflow is counterproductive. The impact of the issue may be
acute due to torflow's control-signal reliance on measurements of marginal
unused bandwidth rather than actual capacity.
To venture a guess, any of queuing (as suggested), chunky event-loop
processing delays, course time precision, misalignment of time
determination vs. data accounting are likely culprits.
Setting milestone was unintended, was thinking of the latest reproducing
version.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25687#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list