Re: [tor-bugs] #22453 [Core Tor/Tor]: Relays should regularly do a larger bandwidth self-test

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

#22453: Relays should regularly do a larger bandwidth self-test
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  juga
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.0.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  034-triage-20180328,                 |  Actual Points:
  034-removed-20180328, tor-bwauth,              |
  035-backport, 034-backport-maybe, 033          |
  -backport-maybe, 029-backport-maybe-not        |
Parent ID:  #25925                               |         Points:
 Reviewer:  teor                                 |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by arma):

 Replying to [comment:28 teor]:
 > > I don't think sbws suffers from similar issues, so once all the
 torflow scanners are gone, we can disable the bandwidth self-test code.
 Until then, it should be on and larger.

 I don't think we need to wait for all of the torflows to be gone. Isn't it
 enough to have one sbws scanner? Since that scanner would generate
 appropriate load on relays? And if we're worried that one isn't a stable
 situation, we should work on getting a second one, rather than messing
 with this design?

 > I am not sure if sbws suffers from similar issues, but it *does* need
 accurate self-reported observed relay bandwidths.

 Nobody is proposing to rip out the "relays passively observe how much
 traffic they carry and publish their capacity estimate in their
 descriptor" design here. So, sounds good, sbws will still get the same
 thing we have now in terms of accurate self-reported observed relay
 bandwidths.

 > And bridges need self-measured bandwidths, because they don't have a
 bandwidth scanner:

 I think we need to figure out a use for bridge bandwidth values before we
 worry about how to make them a bit more accurate. For bridges that don't
 see much use anyway, having a bigger number or not isn't going to be a big
 change, right?

 To be more concrete, I think approximately nothing uses the bridge
 descriptor bandwidth values -- I have a dim memory in the distant past of
 choosing by weight but capping the weight at like 100KBytes so we don't
 send too much traffic toward a tiny number of bridges. But now in
 select_and_add_guard_item_for_sample() I see that we just call
 smartlist_choose() (i.e. uniformly) when sampling a new bridge.

 > > This is especially important for bridges, since they might go long
 periods without much use.
 >
 >
 https://github.com/torproject/tor/blob/12175987fc744f5ca6559a821867631457911451/src/core/mainloop/mainloop.c#L2271

 I wrote that comment (commit 43dce232), back when we were going to do a
 lot more with the bridge design than we ended up doing -- and I now think
 the comment is wrong. :)

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