Opened 3 years ago

Closed 2 years ago

#20597 closed enhancement (fixed)

Modify test network schedule start times for exponential backoff

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: doc, triaged-out-20170116
Cc: Actual Points: 0.5
Parent ID: Points: 0.5
Reviewer: Sponsor:

Description

When we fixed #20499, we broke the tor test network schedules.
They need to be tuned just like the client bootstrap authority and bridge client schedules.

This should be quite an easy fix, it just involves changing the initial delay until bootstrap works.

Child Tickets

Change History (10)

comment:1 Changed 3 years ago by teor

Actual Points: 0.5
Status: newneeds_review

There is no initial delay at which bootstrap works in the test network at exponent 4 (multiplier 3).
This is because it takes 5-10 seconds for the initial consensus to be created.
Ideally, we want relays and clients to wait 10 seconds before trying their first download.
Then we want them to download with linear or low multiplier exponential delays starting at 0 or 1.
But the exponential backoff code does not have this option.

If we start with a low delay and high multiplier, by the time that consensus is created, the variance among the backoff times is so high that some clients and relays work, and others do not.

We also can't change these schedules in Tor, because chutney explicitly sets them all to "0, 5". (And the exponential backoff code only uses the initial "0".)

The solution is to reduce the exponent to 3 (multiplier 2), but only in test networks.
(The original exponential backoff code had exponent 2 (multiplier 1), and with delay increments in [0, delay*multiplier]. But I chose exponent 3 (multiplier 2) to get as close to the live network code as possible. It seems just as reliable. It's also worth noting that the delay increments are now in [1, delay*multiplier].)

Perhaps we can make this a configurable option, but that can wait for a later release. Perhaps we could also stop setting these options in chutney as well. But this works well enough for now.

Please see my branch bug20597_029 on github.

comment:2 Changed 3 years ago by teor

Keywords: CoreTorTeam201611 added

comment:3 Changed 3 years ago by nickm

wow, that is messy. this patch looks like an acceptable stopgap, though. So, merging it.

Let's open tickets for an improved solution?

comment:4 Changed 3 years ago by teor

#20604, #20605, #20606, #20607, all parented to #20534 so we remember to document this.

comment:5 Changed 3 years ago by nickm

Keywords: doc added; must-fix-before-0295-alpha regression 029-proposed removed
Milestone: Tor: 0.2.9.x-finalTor: 0.3.0.x-final
Status: needs_reviewnew

comment:6 Changed 3 years ago by nickm

Type: defectenhancement

batch modify: I think these are "enhancement", though I could be wrong about some.

comment:7 Changed 3 years ago by nickm

Keywords: triaged-out-20160116 added
Milestone: Tor: 0.3.0.x-finalTor: unspecified

comment:8 Changed 3 years ago by nickm

Keywords: triaged-out-20170116 added; triaged-out-20160116 removed

comment:9 Changed 2 years ago by nickm

Keywords: CoreTorTeam201611 removed

comment:10 Changed 2 years ago by teor

Resolution: fixed
Status: newclosed

This was fixed, and we opened tickets for the remaining work.

Note: See TracTickets for help on using tickets.