[tor-bugs] #30817 [Core Tor/Tor]: Write a proposal for tor bootstrapping that works on slow links, but avoids slow relays

[Tor Bug Tracker & Wiki]

#30817: Write a proposal for tor bootstrapping that works on slow links, but avoids
slow relays
---------------------------+----------------------------------
 Reporter:  teor           |          Owner:  (none)
     Type:  task           |         Status:  new
 Priority:  Medium         |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  tor-bootstrap  |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:  Sponsor31-can
---------------------------+----------------------------------

Comment (by teor):

 Replying to [comment:1 irl]:
 > This looks a lot like [https://tools.ietf.org/html/rfc8305 Happy
 Eyeballs], which may have some useful considerations in it.

 You're right, there is probably some clever way to do IPv4/IPv6 with this
 proposal as well.

 We will probably need a few different abstractions, so that the complexity
 doesn't overwhelm us.

 Here are some useful abstractions:
 * a directory document request or ORPort connection request
 * an endpoint: an IPv4 ORPort, IPv6 ORPort, and IPv4 DirPort
   * a way of deciding which endpoints are permitted and preferred
 * a relay, with a list of endpoints on that relay
 * a list of endpoints to try
   * a way of deciding when to try the next endpoint
   * relay and authority initial delays
   * number of permitted concurrent connections
 * a connection to an endpoint
 * an in-progress download
   * a way of deciding which downloads are permitted (or cancelled) and
 preferred
   * priority connections
 * a way to check how the connections or downloads are progressing
   * status handlers
 * a way to know when connections or downloads are ready
   * completion handlers

 We could have a basic, low-level interface that takes:
   * a directory document path or ORPort connection request
   * a list of endpoints,
   * a delay mode (or just use tor's default exponential mode),
   * the number of permitted concurrent connections (possibly per-stage:
 TCP, SSL, link, directory, download?),
   * a timeout,
   * a mode for killing connections on timeout (or just decide on a
 default, example: kill stalled connections),
   * a completion handler

 And a status handler that takes an in-progress request, and returns its
 progress.

 Then we could build high-level interfaces that:
   * fetch a document from the local cache, or download that document and
 cache it
   * take a list of directory caches and authorities, and expand them into
 a list of endpoints

 I'm still not sure I have the right abstractions, but I'm getting there.
 We should definitely hide a lot of the complexity in the module, so other
 modules don't have to worry about it.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30817#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online