[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" <blackhole@xxxxxxxxxxxxxx>]

#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         |   Keywords:  tor-bootstrap
Actual Points:                 |  Parent ID:
       Points:                 |   Reviewer:
      Sponsor:  Sponsor31-can  |
-------------------------------+------------------------------
 In #16844, clients on slow links time out before they can download a full
 consensus

 In #21969 and children, relays fail to bootstrap because a directory
 authority limits DirPort download speeds (a similar bug exists for clients
 which try slow relays)

 We need to redesign tor's bootstrap so that tor works when the link is
 slow, but tries another relay when the relay is slow.

 We should implement multiple concurrent downloads for all directory
 documents, not just consensuses. Once we have multiple concurrent
 downloads, we can increase the timeouts substantially.

 We should limit the number of concurrent downloads to 3, because if 3 fast
 relays are all slow, it's probably the link that it slow. And a 3x
 download size is an acceptable cost. (It probably won't be that bad,
 because we delay starting the 2nd and 3rd fetches, and terminate them when
 the first one completes.)

 We could also be a bit more clever, and terminate the download that would
 take the longest time to finish, after a soft timeout. And then reduce the
 number of concurrent downloads by one.

 We could also simplify the relay/authority selection logic:
 * relays try authorities first, then after a delay, they try other relays
 (most relays are directory mirrors, so they do this anyway)
 * clients try relays first, then after a delay, they try authorities

 And simplify the ORPort/DirPort selection logic for directory downloads:
 * clients always download via ORPorts on relays and authorities, for
 security
 * relays always download via DirPorts on authorities, to avoid SSL CPU
 load on a small number of machines
 * relays always download via ORPorts on other relays, for security (CPU
 load doesn't matter that much)

 We could design a new directory download module to implement this logic,
 using pieces of the existing modules, but with a cleaner, high-level
 interface:
 * request a download of a particular directory document, or set of
 directory documents
 * pass a download configuration with:
   * an optional directory cache,
   * ORPort / DirPort preference,
   * number of permitted concurrent connections,
   * relay and authority initial delays,
   * status and completion handlers.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs