Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#20060 closed defect (implemented)

torspec patch for new bandwidth weight defaults

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: 0.3.0.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-auth, nickm-deferred-20161005, CoreTorTeam201610, tor-spec
Cc: pastly Actual Points:
Parent ID: Points: 0.1
Reviewer: Sponsor:

Description (last modified by teor)

If #14881 merges, torspec needs a patch saying that consensus method 24 26 in tor version 0.2.9 0.3.0 0.3.0.1-alpha initialises G, M, E, and D with 1, and T with 4.

Child Tickets

Change History (14)

comment:1 Changed 3 years ago by teor

Parent ID: #14881

comment:2 Changed 3 years ago by nickm

Keywords: nickm-deferred-20161005 added
Milestone: Tor: 0.2.9.x-finalTor: 0.3.0.x-final

Deferring more things -- even ones I love -- to 0.3.0. Please argue if I'm wrong.

comment:3 Changed 3 years ago by nickm

Cc: pastly added

comment:4 Changed 3 years ago by nickm

Description: modified (diff)
Parent ID: #14881

unparenting, to close parent. Editing description to reflect reality.

comment:5 Changed 3 years ago by pastly

Status: newneeds_review

comment:6 Changed 3 years ago by teor

Status: needs_reviewneeds_revision

We should mention that:

  • T is initialised to 4
  • a shart summary of the impact of this change, something like: "With this change, test tor networks that are small or new are much more likely to produce valid bandwidth weights. The extra bandwidth has a negligible impact on the bandwidth weights in the public tor network."

comment:7 in reply to:  6 ; Changed 3 years ago by pastly

Replying to teor:

  • a shart summary of the impact of this change, something like: "With this change, test tor networks that are small or new are much more likely to produce valid bandwidth weights [...]"

Do you mean "more likely to produce invalid bandwidth weights" because we might be giving weight to categories that have no relays? Or do you mean valid because at least we were able to produce a bandwidth-weights line?

comment:8 in reply to:  7 Changed 3 years ago by teor

Replying to pastly:

Replying to teor:

  • a shart summary of the impact of this change, something like: "With this change, test tor networks that are small or new are much more likely to produce valid bandwidth weights [...]"

Do you mean "more likely to produce invalid bandwidth weights" because we might be giving weight to categories that have no relays?Or do you mean valid because at least we were able to produce a bandwidth-weights line?

Ok, so I mean "much more likely to produce a bandwidth-weights line".

We don't need to mention that this might cause node selection issues in small tor networks, because tor thinks there is a node of a particular type, and then can't find one. That's something we should find and fix during the 0.3.0 series.

comment:9 Changed 3 years ago by pastly

Status: needs_revisionneeds_review

Updated branch with new commit.

comment:10 Changed 3 years ago by teor

Description: modified (diff)
Keywords: CoreTorTeam201610 added
Status: needs_reviewmerge_ready

(Fixed the actual first version this will be released in: tor 0.3.0.1-alpha. We don't include versions in dir-spec.txt, so no changes needed.)

Looks good, let's get this squashed and merged to torspec.

comment:11 Changed 3 years ago by nickm

merged!

comment:12 Changed 3 years ago by nickm

Resolution: implemented
Status: merge_readyclosed

comment:13 Changed 2 years ago by teor

Keywords: tor-spec added

Consistently use tor-spec across all tickets (add tor-spec).

comment:14 Changed 2 years ago by teor

Keywords: torspec removed

Consistently use tor-spec across all tickets (remove torspec).

Note: See TracTickets for help on using tickets.