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):

 In relation to the SBWS effort I think it makes sense to preview this by
 running Torflow with the behavior adjustment on Tom Ritter's test scanner.
 That is of course if Tom doesn't mind and perhaps likes the idea.

 The change:  Have aggregate.py substitute the average of self-measure
 bandwidths for the appropriate class in place of self-report bandwidth of
 individual relays when calculating each final vote.  It could even make
 sense to bias off a constant for each class to improve stability of votes
 and consensus medians while retaining class voting biases, e.g. 10000 for
 exits, 9700 for guards, 1200 for middle-only.  Or go a bit radical and
 apply a single constant such as 5000 while folding all relays into a
 single class with an edit to Node::node_class().  Perhaps try out both
 approaches.

 Looking at it now it seems to me Node::node_class() should return
 Exit/Guard/Middle and forget the rest as separate offsets for the
 different roles relays can participate under are not calculated.  Treating
 Exit+Guard and Exit (only) as independent bandwidth classes no longer
 makes sense.  A case might still exist for Guard and Middle since Middle-
 only relays comprise just over half the relay population, though with an
 average bandwidth around 12% of each of the Exit and Guard classes.  Or
 just two classes, 'Exit' and 'NonExit' might work better. . .or one, that
 is no classes.

 While Torflow votes are unitless, they resemble actual bandwidths owing
 that they are interpretations of bandwidth measurements taken at each
 node.  Using class-average bandwidths as baselines for calculating votes
 retains this property.  Probably a correct method is to decay-average
 values in typical manner to mitigate the impact of jitter and drift on
 effective valuation of older votes before replacement.  On the other hand
 hammering in reasonable constants is expedient for a test and will save
 some trouble.  While I'm on the subject of aging votes, seems to me
 measuring guard relays less frequently than non-guards is unhelpful and
 should be binned.

 Was recently reading Torflow code and wrote a script approximating Torflow
 calculations.  Am dangerous enough now to write a patch implementing the
 above.

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