Re: [tor-bugs] #28281 [Core Tor/Tor]: outline of high-level bootstrap tracker abstractions

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#28281: outline of high-level bootstrap tracker abstractions
--------------------------+------------------------------------
 Reporter:  catalyst      |          Owner:  catalyst
     Type:  task          |         Status:  assigned
 Priority:  Medium        |      Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  s8-boostrap   |  Actual Points:
Parent ID:  #28018        |         Points:  0.5
 Reviewer:                |        Sponsor:  Sponsor8
--------------------------+------------------------------------

Comment (by catalyst):

 After chatting some with ahf, I thought it might be a good idea to write
 down here a proposed new set of bootstrap phases. The numbering of the new
 phases is yet to be determined, but they're meant to be in order. (Some
 phases might get skipped, and that's OK.)

 Some design considerations include the spacing between phases. Right now
 many of them seem separated by 5%, which seems to be a decent amount of
 progress as seen by the user's eye. Any increments smaller than this
 aren't necessarily meaningful to show to the user, but we could use the
 smaller increments to add phase names that could give a more accurate
 picture about where something is broken than the user currently gets.

 There are two gaps in the existing phases, one of which corresponds to
 incremental progress downloading descriptors. (The other one doesn't seem
 to currently be used to display incremental progress downloading a
 consensus.)

   `undef`::
     shouldn't be visible to controllers or users
   `starting`::
     can stay the same

 The following high-level grouping of phases should deal with the first
 outbound connection to a Tor relay. This might be to a directory cache, a
 proxy, or a guard/bridge. Here we use "first" to mean whichever one has
 made the most progress so far, in case we open multiple connections before
 any one is fully open.

   `connecting`::
     the initial outbound TCP connection toward the Tor network, for any
 purpose, which might include a firewall-bypassing proxy, or a pluggable
 transport; corresponds to `OR_CONN_STATE_CONNECTING`
   `proxy_handshake`::
     the initial handshake with a firewall-bypass proxy or PT; corresponds
 to `OR_CONN_STATE_PROXY_HANDSHAKING`; might be skipped if not using
 proxies or PTs

 Maybe insert additional phases here for intermediate proxy handshaking
 steps?

   `tls_handshake`::
     the TLS handshake with the first relay; corresponds to
 `OR_CONN_STATE_TLS_HANDSHAKING` or related ORCONN states (some of these
 involve TLS protocol renegotiations to deal with older link protocol
 versions)
   `open`::
     the Tor link protocol is open to the first relay and can send and
 receive cells

 The following high-level grouping of phases should deal with receiving and
 verifying directory information. Some of these might get skipped if we're
 starting from cached info.

   `dir_circ_create`::
     corresponds to the `CREATE` command opening the first circuit to a
 directory server; maybe reuse the existing `onehop_create` tag, because it
 already mostly means this? it might be better to have the more normalized
 naming though
   `dir_circ_created`::
     corresponds to the `CREATED` response that means the first directory
 circuit is created
   `dir_stream_begin`::
     corresponds to the `BEGIN_DIR` command
   `dir_stream_connected`::
     corresponds to the `CONNECTED` response to the `BEGIN_DIR` command;
 the existing `requesting_status` phase actually gets sent here instead of
 where the corresponding work actually begins
   `requesting_bridge_desc`::
     start downloading the bridge descriptor, if we're connected to a
 bridge; this is related to #11966
   `requesting_status`::
     this can stay the same
   `loading_status`::
     this can stay the same

 Right now there is a gap (from 20 to 40) between these two phases, but we
 don't currently fill it in with incremental progress in downloading the
 consensus. Maybe we should?

   `loading_keys`::
     this can stay the same
   `requesting_descriptors`::
     this can stay the same
   `loading_descriptors`::
     this can stay the same

 Right now there is a gap between `loading_descriptors` and the next phase
 (from 50 to 80), which we fill in with incremental progress. Maybe we
 should retain this gap and the incremental progress display?

 The next high-level grouping of phases corresponds to connecting to a
 guard, if bridges aren't in use. Similarly to the `connecting` grouping,
 these represent the furthest progress that any one attempt has made so
 far.

   `guard_connecting`::
     same as `connecting` but for a guard
   `guard_proxy_handshake`::
     same as `proxy_handshake` but for a guard
   `guard_tls_handshake`::
     same as `tls_handshake` but for a guard
   `guard_open`::
     same as `open` but for a guard

   `circ_create`::
     same as `dir_circ_create` except for an application circuit
   `circ_created`::
     same as `dir_created` except for an application circuit
   `circ_extend`::
     corresponds to `EXTEND` command for the second hop
   `circ_extended`::
     corresponds to `EXTENDED` response for the second hop
   `circ_exit_extend`::
     corresponds to `EXTEND` command for the exit
   `circ_exit_extended`::
     corresponds to `EXTENDED` response for the exit

   `done`::
     same as existing phase

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28281#comment:3>
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