Opened 5 months ago

Last modified 4 weeks ago

#28018 assigned enhancement

Improve accuracy and usefulness of information reported to controllers about bootstrap status

Reported by: nickm Owned by: catalyst
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ex-sponsor8, 040-deferred-20190220
Cc: brade, mcs, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor19-must


Creating this item as an expansion/clarification of #22266, to better match our roadmap.

The goal here is to improve what Tor reports to controllers about our bootstrapping status, so they can better inform the user -- especially for the purpose of troubleshooting what has gone wrong.

Child Tickets

#11966defectneeds_revision"Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge users
#22266taskclosedcatalystgather info on jump-to-80% issues
#23605defectclosedcatalystexpired consensus causes guard selection to stall at BOOTSTRAP PROGRESS=80
#24661defectclosedteoraccept a reasonably live consensus for guard selection
#27100enhancementclosedcatalystreport connection to PT SOCKS proxy separately from OR connection
#27102taskclosedcatalystgather feedback re decoupling bootstrap progress numbers from BOOTSTRAP_STATUS enum values
#27103enhancementclosedcatalystreport initial OR_CONN as the earliest bootstrap phases
#27104enhancementassignedcatalystreport intermediate status when building application circuits
#27308enhancementassignedcatalystreport bootstrap phase when we actually start, not just unblock something
#27402enhancementclosedcatalyststop reporting "internal paths" during bootstrap
#27691enhancementnewreset bootstrap progress when enough things change
#28281taskassignedcatalystoutline of high-level bootstrap tracker abstractions
#28351enhancementassignedTest clock skewed clients using chutney
#28591defectclosedteorAccept a future consensus for bootstrap
#28731defectclosedcatalystlog bootstrap tag name for easier troubleshooting
#28813taskclosedcatalystconfirm hypothesis re PT jump-to-80%
#28884enhancementclosedcatalystPT users still have a jump-to-80% problem
#28925defectassignedcatalystdistinguish PT vs proxy for real in bootstrap tracker
#28928taskclosedcatalystupdate control-spec.txt for new bootstrap phases
#28929defectclosedcatalystfix typo/mispaste in BOOTSTRAP_STATUS_AP_CONN_PROXY summary text
#28930enhancementassignedahfconsider reordering PT/proxy phases

Change History (8)

comment:1 Changed 5 months ago by mcs

Cc: brade mcs added

comment:2 Changed 4 months ago by nickm

Milestone: Tor: 0.3.6.x-finalTor: 0.4.0.x-final

Tor 0.3.6.x has been renamed to 0.4.0.x.

comment:3 Changed 4 months ago by mcs

For #27239, I reviewed the child tickets of this ticket and thought about how Tor Launcher / Tor Browser will be affected. I added a few comments in other tickets, in some cases asking for clarification about what is planned. I have a few general comments:

Overall, the direction the Network Team has taken should bring some nice improvements to Tor Browser users. Some of the tor changes seem to require a lot of work, and I appreciate the effort that is being put into all of this.

I already mentioned this briefly in ticket:22266#comment:26, but I want to also mention it here: tor itself should try to provide status and error information in a UI-agnostic way. What I mean by that is that tor should support many kinds of status and error reporting interfaces and not lock clients into a particular way of doing things. For example, for Tor Launcher we might implement what is proposed in #23971 (a multi-step progress bar that includes clearly delineated phases). Or we might build something that looks more like a series of checkmarks (one for each bootstrap phase) with some kind of intermediate progress display. But someone else might want to build something completely different.

Another issue that is related to improved bootstrap status reporting is improved error reporting. Do we have a ticket or set of tasks that cover that area? Maybe adding more phases will be enough, but there may be more that should be done. For example, being able to tell users exactly where a failure occurred would be very helpful; currently, it is difficult to distinguish local network problems from a PT problem from a wider Tor network problem.

We are looking forward to making whatever changes are needed in to Tor Launcher / Tor Browser to accommodate the improvements. As you proceed, please help us by being clear about what has changed (hopefully control spec updates will be sufficient to communicate the changes).

comment:4 Changed 4 months ago by arma

Keywords: sponsor19-also added

Adding a note: this is a critical-path ticket for Sponsor19 as well (e.g. for #23839)

Last edited 4 months ago by arma (previous) (diff)

comment:5 Changed 4 months ago by arma

Cc: arma added

comment:6 Changed 3 months ago by gaba

Keywords: ex-sponsor8 added; sponsor19-also removed
Sponsor: Sponsor8-mustSponsor19-must

comment:7 Changed 3 months ago by gaba

Moving it to sponsor19. Let's talk about which part of this can be done for s19.

comment:8 Changed 4 weeks ago by nickm

Keywords: 040-deferred-20190220 added
Milestone: Tor: 0.4.0.x-finalTor: unspecified

Deferring 51 tickets from 0.4.0.x-final. Tagging them with 040-deferred-20190220 for visibility. These are the tickets that did not get 040-must, 040-can, or tor-ci.

Note: See TracTickets for help on using tickets.