[tor-bugs] #9574 [Tor]: Process ntor create cells before tap create cells?

[Tor Bug Tracker & Wiki]

#9574: Process ntor create cells before tap create cells?
-----------------------------+---------------------------------------
     Reporter:  arma         |      Owner:
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-relay, maybe-proposal
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+---------------------------------------
Changes (by isis):

 * cc: isis@… (added)


Comment:

 I tested and this seems to be working, I also briefly reviewed the
 patches. Attached is the torrc for that relay and some info logs plus the
 events from `SETEVENTS EXTENDED CIRC CLIENTS_SEEN INFO DESCCHANGED
 BUILDTIMEOUT_SET`.

 CPU went from wavering around 400% (with `NumCPUs 4`) to 80%-140%. I had
 one failure before this patch from lack of available fds, which had been
 ~3900 out of 4096 for several days -- now fd levels are at ~1200/4096.
 It's still getting CIRC FAILEDs, but I think this is from the other relays
 not being able to handle more circuits.

 Replying to [comment:12 nickm]:
 >   * The code in onion_next_task is too aggressive: it does "never answer
 a TAP request while any ntor request is pending", which means that in
 practice I doubt we'll answer TAP requests at all on a busy node.

 Mine isn't the biggest exit relay, I think it's only 0.15% of the total
 exit capacity, but the TAP queues so far have stayed pretty low. That
 might change if more relays start running with these patches.

 > Here are some other ideas we could take:
 >      * Always answer at least N ntor requests for every 1 TAP request,
 if we have both.  (N=5? 10?)
 >      * When we have both ntor and TAP requests, choose an ntor request
 with probability P.  (P=.8? P=.9?)
 >      * When we have both ntor and TAP requests, choose an ntor request
 unless the oldest pending TAP request is N msec older than the oldest
 pending ntor request. (N=???)
 >      * What else?
 >
 > Also, does this imply that we ought to start designing a handshake with
 scalable client proof-of-something?
 >


 I wanted PoW for BridgeDB, researched it a bit (see
 [https://trac.torproject.org/projects/tor/ticket/7520#comment:14
 #7520:comment14]), wasn't very hopeful about finding a workind PoW scheme,
 and then phw convinced me that anything we expect a Tor client to do, an
 adversary can certainly do. Though I would really love to see this proven
 wrong.

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