Re: [tor-bugs] #17810 [Core Tor/Torflow]: TorFlow should ignore self-reported bandwidths when measuring relays

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#17810: TorFlow should ignore self-reported bandwidths when measuring relays
------------------------------+------------------------
 Reporter:  robgjansen        |          Owner:  (none)
     Type:  defect            |         Status:  new
 Priority:  Medium            |      Milestone:
Component:  Core Tor/Torflow  |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:                    |  Actual Points:
Parent ID:                    |         Points:
 Reviewer:                    |        Sponsor:
------------------------------+------------------------

Comment (by starlight):

 Replying to [comment:18 robgjansen]:
 > > While Torflow votes are unitless, they resemble actual bandwidths
 owing that they are interpretations of bandwidth measurements taken at
 each node.
 >
 > Careful here. I think TorFlow measures something closer to residual
 bandwidth capacity at the time of the measurement, not the full capacity
 of the link.

 Yes, of course.

 >And it doesn't even measure residual capacity exactly, because of
 scheduling and fairness. For example, if my relay is operating at 100%
 link utilization and TorFlow tries to measure it, TorFlow isn't going to
 get 0 bandwidth and it isn't going to get 100% bandwidth; TorFlow is
 probably only going to get roughly 1/N of my bandwidth where N is the
 number of other active flows.
 >
 > Or am I misunderstanding and the authorities interpret the measurements
 differently?

 I may not have this perfectly, but it seems to me that Torflow calculates
 the ratio/percent offset of the measurement for each relay relative to the
 average of all relay measurements (or all relays handled by the particular
 scanner, not sure).  Then this value feeds into the "PID error", which
 presently is limited just the "P" or progressive component and so is in
 effect a pass-through of the scanner offset.  Is then applied to the self-
 measure of a node under consideration, thereby mirroring of the residual
 bandwidth offset onto the actual declared bandwidth.  That's why Torflow
 votes somewhat resemble real bandwidth capacities.  Votes could just as
 easily have an arbitrary basis so long as the consensus fractions work out
 the same, but it's nice to have semi-reasonable values to look at.

 The request in this ticket and one of the stated design goals of SBWS is
 to take self-measure out of voting process, but I am highly skeptical that
 this will turn out to be practical.  Certainly plugging averages of whole
 class (exit/guard/middle) self-measurements in place of per-relay self-
 measure looks terrible in the spread-sheet.  Can be seen by sorting on a
 hypothetical vote column and glancing over at the Maatuska vote and
 consensus weight columns.  I may try revising it with averages specific to
 each scanner to see if this helps, but I doubt it.

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