[tor-bugs] #16675 [Torflow]: BWauth longclaw outlier

[Tor Bug Tracker & Wiki]

#16675: BWauth longclaw outlier
-----------------------+------------------------
 Reporter:  starlight  |          Owner:  aagbsn
     Type:  defect     |         Status:  new
 Priority:  normal     |      Milestone:
Component:  Torflow    |        Version:
 Keywords:             |  Actual Points:
Parent ID:             |         Points:
-----------------------+------------------------
 This ticket is somewhat vague due to my lack of
 familiarity with the inner workings of TorFlow
 and lack of access to a the system in question
 It consists of an observed artifact that
 may be attributable to one of the more
 specific issues.  Please feel free to close
 it out and/or note where it might belong.

 For the last two weeks BWauths have been
 generating measurements with apparently
 improved rationality.  Not sure what
 change caused that but it's a very welcome
 development.

 On July 22 'longclaw' stopped updating
 bandwidth measurements for four days,
 but was restored about a day ago and
 is now working.

 'longclaw' has, in the last few hours,
 produced an large outlier observation
 for a Verizon FiOS relay relative to
 a group of similar relays.  Understanding
 the cause may help further improve the
 state of TorFlow.

 The following relays all operate on
 fast symmetrical FiOS connections in the
 North Eastern US.  Since the improved
 behavior appeared, these relays generally
 are measured with increasing bandwidth
 in the order

 {{{

 longclaw
 gabelmoo
 maatuska
 moria1

 First a close-match and typical observation
 as of 17:00 GMT 2015-07-27:

 Binnacle
 longclaw Bandwidth=8055 Measured=5350
 gabelmoo Bandwidth=8055 Measured=8830
 maatuska Bandwidth=8055 Measured=9370
 moria1   Bandwidth=8055 Measured=21500

 Now for the outlier, a relay very
 similar to the above though it
 appears to have 30% more bandwidth
 available to the relay:

 EmbraceTheChaos
 longclaw Bandwidth=6986 Measured=33700
 gabelmoo Bandwidth=6986 Measured=9090
 maatuska Bandwidth=6986 Measured=9710
 moria1   Bandwidth=6986 Measured=48200

 The above measure appeared abruptly in
 2015-07-27-09-00-00-vote-23D . . .
 and in the prior vote was the more
 rational, consistent and typical

 Bandwidth=6986 Measured=4710

 =====

 Additional similar relays:

 ZzZzZz
 longclaw Bandwidth=6270 Measured=2530
 gabelmoo Bandwidth=6270 Measured=5530
 maatuska Bandwidth=6270 Measured=6420
 moria1   Bandwidth=6270 Measured=16600

 AGoodFellow
 longclaw Bandwidth=4082 Measured=2620
 gabelmoo Bandwidth=4082 Measured=4950
 maatuska Bandwidth=4082 Measured=8730
 moria1   Bandwidth=4082 Measured=9740

 UrbanRelayUT
 longclaw Bandwidth=3145 Measured=2540
 gabelmoo Bandwidth=3145 Measured=2880
 maatuska Bandwidth=3145 Measured=6740
 moria1   Bandwidth=3145 Measured=5380

 JumpPoint
 longclaw Bandwidth=2777 Measured=2470
 gabelmoo Bandwidth=2777 Measured=2800
 maatuska Bandwidth=2777 Measured=4440
 moria1   Bandwidth=2777 Measured=5340

 12xBTM1
 longclaw Bandwidth=2037 Measured=1020
 gabelmoo Bandwidth=2037 Measured=2220
 maatuska Bandwidth=2037 Measured=1860
 moria1   Bandwidth=2037 Measured=3030

 }}}

 The though behind this ticket is it
 may be worth analyzing specific examples
 of apparently unsensible measurments
 made by TorFlow.  Due to the homogenous
 and generally high-quality nature of
 the Verizon FiOS network this is a
 reasonable data point.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16675>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online