Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?
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 (legacy/trac#9574 (moved)).
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?