[tor-bugs] #25096 [Core Tor/Tor]: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Jan 31 08:00:49 UTC 2018


#25096: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?
------------------------------+--------------------------------
     Reporter:  arma          |      Owner:  (none)
         Type:  defect        |     Status:  new
     Priority:  Medium        |  Milestone:  Tor: 0.3.3.x-final
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:
Actual Points:                |  Parent ID:
       Points:                |   Reviewer:
      Sponsor:                |
------------------------------+--------------------------------
 Right now the consensus is voting NumNTorsPerTAP=100, i.e. relays will
 handle one tap handshake for every 100 ntor handshakes they handle. We put
 this feature into place during the 2013 botnet overload (#9574).

 TAP handshakes are used by obsolete clients (we don't know how many of
 these remain, but I think it might be quite few), and for v2 onion service
 clients reaching intro points, and for v2 onion services reaching
 rendezvous points.

 With the recent overload that has to do with v2 onion services, the TAP
 frequency has gone up, e.g.
 {{{
 Jan 30 11:46:23.580 [notice] Circuit handshake stats since last time:
 1350439/1350439 TAP, 68743431/68743431 NTor.
 Jan 30 17:46:23.592 [notice] Circuit handshake stats since last time:
 1183340/1183340 TAP, 71590118/71590118 NTor.
 Jan 30 23:50:19.525 [notice] Circuit handshake stats since last time:
 1069004/1069004 TAP, 72357977/72357977 NTor.
 }}}
 It's still low compared to the NTor frequency, but 1M TAP handshakes per 6
 hours is 46 second per second to my relay.

 (Also note that these log messages don't include stats from client
 connections, because we wanted to leave those out to be cautious about
 client privacy.)

 The key realization here is that we can squeeze down v2 onion service
 usage, by squeezing down the prioritization for TAP handshakes.

 Now, on my relay above, I'm able to handle all of both kinds, so changing
 the ratio will just change which cells get answered first -- and given
 that ntor cells are so much cheaper to answer than tap cells, there could
 be a moderate win there.

 But for relays that can't handle the load, if they're similarly getting
 1:70 ratios, we could potentially have a much bigger impact by cranking up
 the balance. If we got to the point where most of the ntors are handled
 and some of the taps are left unhandled, that seems like a fine balance.

 So: good idea, bad idea? And if good idea, what's a good new number? 500?
 1000?

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


More information about the tor-bugs mailing list