Re: [tor-bugs] #33871 [Core Tor/sbws]: Scale exactly as torflow does?

[Tor Bug Tracker & Wiki]

#33871: Scale exactly as torflow does?
-+-
 Reporter:  juga |  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:  #33775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 Oh I missed that sbws was including avg_bandwidth in the min().. That
 definitely should not be there. Average will always be below observed, and
 we want observed or burst because burst can be limited by config by
 operators who don't want traffic, giving them at least one (admittedly
 sloppy) knob to try to reduce traffic.

 I just dug a bit deeper into the 0 bw issue, and I found that we actually
 set it to at leasty 1, to simplify computation. This is done in the
 TorCtl.Router class:
 https://gitweb.torproject.org/pytorctl.git/tree/TorCtl.py#n379

 So we should probably do something that in sbws too (either hack to 1 or
 riddle with special cases everywhere), so we can still measure 0-bw
 relays.

 FYI: There is a related hack for Unmeasured=1 relays here:
 https://trac.torproject.org/projects/tor/ticket/6131

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #34224 [Metrics/Onionperf]: Update analysis results file version to 2.0

[Tor Bug Tracker & Wiki]

#34224: Update analysis results file version to 2.0
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 In retrospect, the patch is trivial enough to go into master without
 explicit review. After all, we concluded that the new version would be the
 string `"2.0"` on Thursday. Merging and closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #34224 [Metrics/Onionperf]: Update analysis results file version to 2.0

[Tor Bug Tracker & Wiki]

#34224: Update analysis results file version to 2.0
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:  0.2
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * actualpoints:   => 0.2


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33871 [Core Tor/sbws]: Scale exactly as torflow does?

[Tor Bug Tracker & Wiki]

#33871: Scale exactly as torflow does?
-+-
 Reporter:  juga |  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:  #33775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:14 mikeperry]:
 > Oh I missed that sbws was including avg_bandwidth in the min().. That
 definitely should not be there. Average will always be below observed,

 I don't think this is the case, just taking randomly a relay from my
 `cached-descriptors`:
 {{{
 router rotateRelay21 188.227.170.106 2109 0 0
 fingerprint 1387 BB67 C0A1 BCE2 8133 FF72 39E0 27D5 4C56 538D
 bandwidth 2621440 10485760 5445375
 }}}

 I also looked 2 years ago at the spec and the code
 (https://onbasca.readthedocs.io/en/latest/bandwidth_tor.html) and
 concluded that the average is `min(RelayBandwidthRate, BandwidthRate,
 MaxAdvertisedBandwidth)`, which are all set by the operator (or torrc
 defaults), am i mistaken?.
 Maybe you're thinking on the `advertised` bandwidth, not the average?

 > and we want observed or burst because burst can be limited by config by
 operators who don't want traffic, giving them at least one (admittedly
 sloppy) knob to try to reduce traffic.

 I agree with this, but for the same reason we should also limit it by the
 average
 (https://gitweb.torproject.org/sbws.git/tree/sbws/lib/v3bwfile.py#n1340)

 >
 > I just dug a bit deeper into the 0 bw issue, and I found that we
 actually set it to at leasty 1, to simplify computation. This is done in
 the TorCtl.Router class:
 https://gitweb.torproject.org/pytorctl.git/tree/TorCtl.py#n379
 >
 > So we should probably do something that in sbws too (either hack to 1 or
 riddle with special cases everywhere), so we can still measure 0-bw
 relays.

 Yes, we're doing that in sbws, note that in my previous reply i included a
 `1` in the `new_bw` equations, ie. `new_bw = min(consensus bandwidth,
 descriptor observed bandwidth, descriptor average bandwidth, descriptor
 burst bandwidth, 1) * ratio`

 What i mean is that it's a different thing to calculate the minimum when
 one of those values is 0 (the result will be 1) or to exclude one of those
 values when it's 0 (the result will be greater or equal than 1).

 Note that AFAIU, Torflow code is not calculating the `new_bw` using the
 consensus bandwidth, though, it just does not produce any bandwidth file
 if any consensus bandwidth is missing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33871 [Core Tor/sbws]: Scale exactly as torflow does?

[Tor Bug Tracker & Wiki]

#33871: Scale exactly as torflow does?
-+-
 Reporter:  juga |  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:  #33775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:15 juga]:
 [snip]
 > > I just dug a bit deeper into the 0 bw issue, and I found that we
 actually set it to at leasty 1, to simplify computation. This is done in
 the TorCtl.Router class:
 https://gitweb.torproject.org/pytorctl.git/tree/TorCtl.py#n379
 > >
 > > So we should probably do something that in sbws too (either hack to 1
 or riddle with special cases everywhere), so we can still measure 0-bw
 relays.
 >
 > Yes, we're doing that in sbws, note that in my previous reply i included
 a `1` in the `new_bw` equations, ie. `new_bw = min(consensus bandwidth,
 descriptor observed bandwidth, descriptor average bandwidth, descriptor
 burst bandwidth, 1) * ratio`

 Oh, sorry, i wanted to put all in 1 line, but this ^ would be always `1`
 :)
 So it should be the maximum between any bandwidth value and 1 and then the
 minimum with those.
 I realized that we're actually taking the maximum of the new bandwidth and
 1 at the very end, which would be also different to take the maximum of
 any bandwidth value an 1 before multiplying by the ratio. We should
 probably do it in this last way, as torflow does.

 >
 > What i mean is that it's a different thing to calculate the minimum when
 one of those values is 0 (the result will be 1) or to exclude one of those
 values when it's 0 (the result will be greater or equal than 1).
 >
 > Note that AFAIU, Torflow code is not calculating the `new_bw` using the
 consensus bandwidth, though, it just does not produce any bandwidth file
 if any consensus bandwidth is missing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #34234 [Applications/Tor Browser]: Use Debian 10 for our https-everywhere container image

[Tor Bug Tracker & Wiki]

#34234: Use Debian 10 for our https-everywhere container image
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:  #31127
   Points:|   Reviewer:
  Sponsor:|
--+--
 We are currently using Debian Stretch to build https-everywhere for any
 platform.

 We can update that to Debian 10.

 It looks like the https-everywhere build still requires python3.6 while
 Debian 10 provides version 3.7, so we still need our own build of
 python3.6. However the update to Debian 10 will allow us to share the
 python3.6 build with the osx64 and windows builds as they will be using
 Debian 10 too.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #34235 [Metrics/Library]: Release metrics-lib 2.13.0

[Tor Bug Tracker & Wiki]

#34235: Release metrics-lib 2.13.0
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 I'm putting out metrics-lib 2.13.0 today to parse OnionPerf's analysis
 results file format 2.0 (#34224).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #34235 [Metrics/Library]: Release metrics-lib 2.13.0

[Tor Bug Tracker & Wiki]

#34235: Release metrics-lib 2.13.0
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Release: https://dist.torproject.org/metrics-lib/2.13.0/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #34023 [Metrics/Onionperf]: Reduce the number of 50 KiB downloads

[Tor Bug Tracker & Wiki]

#34023: Reduce the number of 50 KiB downloads
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-team-roadmap-2020  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  Sponsor59-must
---+
Changes (by karsten):

 * Attachment "onionperf-partials-2020-05-16.pdf" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33435 [Metrics/Onionperf]: Document BASETORRC environment variable

[Tor Bug Tracker & Wiki]

#33435: Document BASETORRC environment variable
---+
 Reporter:  acute  |  Owner:  phw
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-team-roadmap-2020  |  Actual Points:
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by acute):

 Replying to [comment:4 phw]:
 > Here's a patch that documents `BASETORRC` in the file
 onionperf/docs/onionperf.rst:
 > https://github.com/NullHypothesis/onionperf/compare/enhancement/33435
 >
 > The patch also adds a table of contents to onionperf's README, which
 makes it easier to browse.
 The patch looks good, I think this can be merged!

 >
 > I wonder if we should merge README.md with onionperf.rst. The two files
 contain redundant installation instructions and I found it confusing that
 more documentation was hidden in the source code directory.

 These two were intended to serve different purposes. The readme was meant
 to be a quick reference, and the docs an in-depth guide which includes
 module documentation (sphinx autodoc can be used to build documentation
 from docstrings) and more exotic deployment options (for say,
 researchers). The docs are currently served here:
 https://onionperf.torproject.org

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33435 [Metrics/Onionperf]: Document BASETORRC environment variable

[Tor Bug Tracker & Wiki]

#33435: Document BASETORRC environment variable
---+
 Reporter:  acute  |  Owner:  phw
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-team-roadmap-2020  |  Actual Points:
Parent ID: | Points:  0.3
 Reviewer: |Sponsor:  Sponsor59-must
---+
Changes (by acute):

 * status:  needs_review => merge_ready
 * points:  0.2 => 0.3


Comment:

 Adding my 0.1 points to yours.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #34023 [Metrics/Onionperf]: Reduce the number of 50 KiB downloads

[Tor Bug Tracker & Wiki]

#34023: Reduce the number of 50 KiB downloads
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-team-roadmap-2020  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by karsten):

 With #26673 being resolved we now have partial completion times available.
 That means that we have timestamps when a 5 MiB download completed the
 first 50 KiB or 1 MiB and when a 1 MiB download completed the first 50
 KiB.

 I reprocessed past measurement results from op-hk2, op-nl2, and op-us2
 from the first two weeks of May 2020 to see whether we can use partial
 completion times of larger downloads together with full download
 completion times.

 Here are some remarks on the
 [https://trac.torproject.org/projects/tor/attachment/ticket/34023
 /onionperf-partials-2020-05-16.pdf attached PDF]:

  1. The first plot shows number of measurements without (green) and with
 (purple) including partial downloads. The number of 50 KiB measurements
 increases by about 1/5, which includes both 1 MiB and 5 MiB downloads. The
 number of 1 MiB measurements increases by about 1/2 as compared to before,
 which only includes the 5 MiB downloads. The number of 5 MiB downloads
 stays the same, because there are no larger downloads than 5 MiB.

  2. The second plot shows ECDFs of time to download 50 KiB. Each of the
 subplots contains two lines, one in green and one in purple. They are just
 so similar that they're basically indistinguishable. The purple line
 contains 20% more data points than the green line, but that doesn't make
 any visible difference.

  3. The third plot shows ECDFs of time to download 1 MiB. Interestingly,
 there are some minor differences between the green and purple line. The
 reason is that the purple line contains 50% more data points than the
 green line. That's a larger difference than the additional 20% in the 50
 KiB case. Still, there doesn't seem to be systematically different
 measurements when including partial completion times or not.

  4. The fourth plot shows ECDFs of time to download 5 MiB. I only included
 this as a way to sanity check the plotting code. Green and purple lines
 are exactly the same here, because we have as many partial completion
 times for 5 MiB downloads as full download completion times.

 Let's discuss how to proceed with these results. My recommendation is that
 we:

  1. extend the [https://metrics.torproject.org/torperf.html "Time to
 download files over Tor" graph on the Tor Metrics website] to include
 partial completion times, if available, and

  2. modify deployed OnionPerf instances to ''only'' download 5 MiB files
 and no 50 KiB or 1 MiB files anymore.

 Leaving in needs_review to get feedback. I'll also bring this ticket up at
 the next weekly meeting on Thursday.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #33434 [Metrics/Onionperf]: Allow users to select Onion Service version to measure

[Tor Bug Tracker & Wiki]

#33434: Allow users to select Onion Service version to measure
---+
 Reporter:  acute  |  Owner:  karsten
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-team-roadmap-2020  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:  Sponsor59-must
---+
Changes (by karsten):

 * status:  new => accepted
 * owner:  metrics-team => karsten


Comment:

 I'll work on this ticket in the next couple days.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #34236 [Core Tor/Tor]: Fix spacing in if statement in port_parse_config()

[Tor Bug Tracker & Wiki]

#34236: Fix spacing in if statement in port_parse_config()
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This line in `port_parse_config()`:

 {{{
 if ( has_used_unix_socket_only_option && ! unix_socket_path) {
 }}}

 should be:

 {{{
 if (has_used_unix_socket_only_option && !unix_socket_path) {
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #34236 [Core Tor/Tor]: Fix spacing in if statement in port_parse_config()

[Tor Bug Tracker & Wiki]

#34236: Fix spacing in if statement in port_parse_config()
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => needs_review


Comment:

 PR: https://github.com/torproject/tor/pull/1894

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #34237 [Core Tor/Tor]: Fix spacing in if statement in tor_version_parse()

[Tor Bug Tracker & Wiki]

#34237: Fix spacing in if statement in tor_version_parse()
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This if statement in tor_version_parse():

 {{{
 if ( hexlen == 0 || (hexlen % 2) == 1)
 }}}

 should be:

 {{{
 if (hexlen == 0 || (hexlen % 2) == 1)
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #34237 [Core Tor/Tor]: Fix spacing in if statement in tor_version_parse()

[Tor Bug Tracker & Wiki]

#34237: Fix spacing in if statement in tor_version_parse()
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => needs_review


Comment:

 PR: https://github.com/torproject/tor/pull/1895

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #34238 [Core Tor/Tor]: Space out tor_assert() call in parse_short_policy()

[Tor Bug Tracker & Wiki]

#34238: Space out tor_assert() call in parse_short_policy()
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs