Opened 4 months ago

Last modified 6 weeks ago

#27103 assigned enhancement

report initial OR_CONN as the earliest boostrap phases

Reported by: catalyst Owned by: catalyst
Priority: Medium Milestone: Tor: 0.4.0.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: usability, ux, ux-team, bootstrap, 035-roadmap-subtask, 035-triaged-in-20180711, s8-bootstrap, s8-errors
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

TicketTypeStatusOwnerSummary
#27167enhancementassignedcatalysttrack "first" OR_CONN
#27169taskclosedmonitor bootstrap directory info progress separately

Change History (10)

comment:1 Changed 4 months ago by catalyst

Keywords: s8-bootstrap added
Sponsor: Sponsor8

comment:2 Changed 4 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 4 months ago by intrigeri

Cc: intrigeri added

comment:4 Changed 4 months 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 4 months 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 months 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 2 months ago by nickm

Parent ID: #22266#28018

comment:8 Changed 2 months ago by catalyst

Keywords: s8-errors added

comment:9 Changed 7 weeks ago by catalyst

Type: defectenhancement

comment:10 Changed 6 weeks 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.

Note: See TracTickets for help on using tickets.