[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:               |
-----------------------------+---------------------------------------

Comment (by mikeperry):

 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.  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?)

 I think this one is my favorite for KISS reasons. We should have a
 consensus parameter for it too, of course. I kind of think we should kill
 TAP with fire and set this at like 100 though, and maybe even provide a -1
 or other magic value that always services ntor first.

 >      * When we have both ntor and TAP requests, choose an ntor request
 with probability P.  (P=.8? P=.9?)

 I loves me some stochastic codez, but this seems overkill?

 >      * 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=???)

 I don't like this one because it will be hard to tune and may end up still
 letting through a lot of TAP cells over ntor, especially under conditions
 like we have now (where we have very little ntor traffic, and a ton of TAP
 traffic).

 >      * What else?

 Should we add extra-info lines for how many CREATE_FAST, TAP and ntor
 cells each node is processing? Or is that too sensitive?

 > Also, does this imply that we ought to start designing a handshake with
 scalable client proof-of-something?

 Seems like it. :/

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