Re: [tor-bugs] #14006 [Core Tor/Tor]: Hidden service error: "We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits..."

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

#14006: Hidden service error: "We'd like to launch a circuit to handle a
connection, but we already have 32 general-purpose client circuits..."
-----------------------------------------------+---------------------------
 Reporter:  asn                                |          Owner:  (none)
     Type:  defect                             |         Status:
                                               |  needs_information
 Priority:  Medium                             |      Milestone:  Tor:
                                               |  0.3.3.x-final
Component:  Core Tor/Tor                       |        Version:
 Severity:  Normal                             |     Resolution:
 Keywords:  tor-hs circuit-management scaling  |  Actual Points:
Parent ID:                                     |         Points:
 Reviewer:                                     |        Sponsor:
-----------------------------------------------+---------------------------

Comment (by asn):

 Replying to [comment:18 dgoulet]:
 > Replying to [comment:15 arma]:
 > > Or oh hey, what about general-purpose circuits to upload new onion
 descriptors? We launch 6 or 8 of those at a time, and if there are several
 onion services being managed by this Tor... we can get to 32 right quick?
 >
 > Yes that is a problem. v2 uses 6 HSDirs so at 6 configured HS, you reach
 32 circuits quickly. v3 uses `hsdir_spread_store` which is currently 4
 meaning 8 HSDirs for every service. You configure 4 services and boom 32
 circuits are launched.
 >
 > But bumping `MaxClientCircuitsPending` is not really a good idea just
 for services.
 >
 > The thing is that once the services have bootstrapped that is descriptor
 uploaded, after that they will re-upload at random timings between each
 other. But that one time at startup, we need the service to upload in
 mass. And this is for tor to try as fast as possible to make the service
 reachable.
 >
 > So could we either:
 >
 > 1) Allow a burst at service startup if you have `num_services *
 num_hsdirs > MaxClientCircuitsPending`. I say service startup because one
 could do 10 `ADD_ONION` at once ;).
 >
 > 2) Have a special limit just for HS like `MaxHSCircuitsPending` and bump
 it to something bigger than 32.
 >
 > 3) Leave everything like this and after a while, once tor will be able
 to launch circuits, the descriptor will get uploaded. The operator just
 needs to deal with the delay.
 >
 > 4) <insert idea>

 I think what I would prefer here is for Tor to rate-limit itself when
 building onion service circuits. Especially so when it has multiple onion
 services, but maybe even when it has only a single one. So instead of
 building all its onion circuits (IPs + hsdir circs) at once, it waits a
 randomized time (around a second?) before building each one.

 That will slightly delay the bootup of HSes, but not by too much, and it's
 better for the health of the network. Not sure if this will be a PITA to
 engineer tho.

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