Re: [tor-bugs] #29494 [Core Tor/Tor]: Optimize interaction between circuitmux and circuitpadding

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

#29494: Optimize interaction between circuitmux and circuitpadding
--------------------------+---------------------------
 Reporter:  mikeperry     |          Owner:  mikeperry
     Type:  enhancement   |         Status:  assigned
 Priority:  Medium        |      Milestone:
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  wtf-pad       |  Actual Points:
Parent ID:                |         Points:  5
 Reviewer:                |        Sponsor:  Sponsor2
--------------------------+---------------------------

Comment (by mikeperry):

 Thoughts since Friday:
 1. Because we decrement tokens early but don't check for bins empty until
 the padding event is sent, we can have a situation where another padding
 or non-padding cell causes us to decrement tokens on the same bin before a
 check, eventually leading to a negative token count in that bin. Right now
 this will trigger a backtrace/fragile assert.
 2. A further optimization is not to send padding if there is at least one
 cell in the cell queue, because the idea of padding is to append cells to
 a burst, not place them in the middle of one that is sitting in the queue.
 However, we'll have to figure out how to update token counts properly in
 this case, as well. And then there is the question as to if it does make
 sense to allow a string of padding cells to get queued up. It actually
 might. But then how much? Perhaps this should be a third ticket.

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