Opened 2 months ago

Last modified 4 days ago

#27103 assigned defect

report initial OR_CONN as the earliest boostrap phases

Reported by: catalyst Owned by: catalyst
Priority: Medium Milestone: Tor: 0.3.6.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: usability, ux, ux-team, bootstrap, 035-roadmap-subtask, 035-triaged-in-20180711, s8-bootstrap
Cc: brade, mcs, linda, isabela, iry, intrigeri Actual Points:
Parent ID: #28018 Points:
Reviewer: Sponsor: Sponsor8

Description

We should always make the earliest bootstrap phases be our first connection to any OR, regardless of whether we already have enough directory info to start building circuits.

When starting to boostrap with existing directory info, there might not be a need to make an initial connection to a bridge or fallback directory server to download directory info. This means that the initial OR_CONN to a bridge or guard displays on a progress bar as 80%, when in fact a fairly "early" dependency (the initial connection to any OR) could be failing.

Intuitively, starting Tor Browser and seeing the progress bar hang at 80% for a very long time is frustrating and misleading. A user who sees the progress bar hang at at 5% or 10% has a much better idea of what's going on.

Existing directory info can be reflected in the progress bar as a rapid jump after the initial OR_CONN succeeds. This seems less likely to frustrate users.

Child Tickets

TicketStatusOwnerSummaryComponent
#27167newtrack "first" OR_CONNCore Tor/Tor
#27169closedmonitor bootstrap directory info progress separatelyCore Tor/Tor

Change History (7)

comment:1 Changed 2 months ago by catalyst

Keywords: s8-bootstrap added
Sponsor: Sponsor8

comment:2 Changed 2 months ago by catalyst

I think we need at least two subtasks:

  • Make a new abstraction to track OR_CONNs and notice whether they're the first connection to any relay since "reset", whatever that means. Maybe DisableNetwork=1 should reset this "first connection" status.
  • Refactor directory info progress into a separate abstraction, instead of calling control_event_bootstrap() directly. This will let us defer reporting of "enough directory info" until we have successfully connected to at least one relay or bridge.

comment:3 Changed 8 weeks ago by intrigeri

Cc: intrigeri added

comment:4 Changed 8 weeks ago by catalyst

Proposed new high-level breakdown of bootstrap phases:

  • initial OR_CONN to any bridge or relay (can be a fallback dir or a guard)
  • obtaining the consensus
  • obtaining descriptors (typically microdescs for clients)
  • building a usable application circuit

We should wait for earlier phases to complete before reporting progress on later phases, even if the later phases have completed (e.g., we already have full or partial directory info from a cache). Consensus and descriptor progress might be the only applicable cases where we need to defer reporting progress.

comment:5 Changed 8 weeks ago by nickm

Sounds good. We should maintain the ability to break those phases into sub-tasks, but the breakdown seems okay to me.

comment:6 Changed 3 weeks ago by catalyst

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

Move my post-freeze 0.3.5 items to 0.3.6.

comment:7 Changed 4 days ago by nickm

Parent ID: #22266#28018
Note: See TracTickets for help on using tickets.