[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #25687 [Core Tor/Tor]: over-report of observed / self-measure bandwidth on fast hardware -- important to torflow / peerflow



#25687: over-report of observed / self-measure bandwidth  on fast hardware --
important to torflow / peerflow
-------------------------------------------------+-------------------------
 Reporter:  starlight                            |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.2.6.10
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-bwauth, needs-research, needs-   |  Actual Points:
  proposal?                                      |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by juga):

 Replying to [comment:16 teor]:
 > Replying to [comment:15 starlight]:

 > > Of course.  Mentioned this because the SBWS patch candidates I read
 implement the behavior, though perhaps this has changed since I looked.
 If the logic is present suggest having a consensus parameter to determine
 whether or not the behavior is in force.  Best of luck!
 >
 > Oh right, maybe I'm wrong then.
 >
 > Juga, does sbws implement torflow's "filtered"option?

 yes, i did [0], since we wanted sbws to be able to behave like torflow
 (and it does [1]) to later decide which scaling algorithm we should have.
 The filtered option doesn't change much, since torflow is taking the
 maximum between that and the stream bandwidth. See the attached graph.
 The point i was trying to make in #comment:11 is:
 - we need to come out with a better algorithm that takes into account
 differently observed bandwidth and measured bandwidth. Measured bandwidth
 has little value in Torflow.
 - we (/i) might need to review how observed bandwidth is obtained
 I think i'll be able to explain this better in a week, since these
 comments get messy across tickets (my fault)

 [0]
 https://github.com/torproject/sbws/blob/master/sbws/lib/v3bwfile.py#L762
 [1]
 https://trac.torproject.org/projects/tor/attachment/ticket/27338/20180905_092840_torflow_sbws.png

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