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

[Tor Bug Tracker & Wiki]

#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):

 Ok, so for simplicity, lying to circpad seems like the right move. If the
 queue is full, its going to be wrong anyway..

 However, the second piece of this ticket is about when to tell circpad
 that a padding cell or normal cell was sent. Right now, we tell circpad
 that a padding cell was sent as soon as its callback to send it fires (via
 circpad_cell_event_padding_sent() from
 circpad_send_padding_cell_for_callback()). With respect to the wire, this
 is incorrect because the cell may still wait around in a circuitmux queue
 for a long time before being sent. This delay may cause the padding system
 to decide to send another padding packet before the one it just sent even
 hits the wire.

 Similarly, we call circpad_cell_event_nonpadding_sent() from
 circpad_deliver_sent_relay_cell_events() (via
 relay_send_command_from_edge_()) and from
 circpad_deliver_unrecognized_cell_events() (via
 circuit_receive_relay_cell()). These calls are *also* before the cell is
 added to the circuitmux queue. This means that circuitpadding may schedule
 padding timers for additional padding that fire before the actual data
 packet makes it through the queue.

 In both cases, this will lead to more padding added to the circuit than we
 wanted to. Worse, it means more padding added to *already busy, saturated,
 and/or stalled circuits*, which is...not a good look.

 I think the right solution is to make these circpad_cell_event_*_sent()
 callbacks from channel_flush_from_first_active_circuit(), possibly right
 after the cell is popped from the queue. This will be about as accurate as
 we can get, because right after this it goes into the outbuf and should
 get sent by KIST within ~10ms, give or take TCP congestion.

 The difficulty with this is that circpad needs to know if this cell is
 padding or not. Since the cell has already been encrypted, we can't just
 inspect the relay command field anymore. We need to add an additional
 bitfield to packed_cell_t. 1 bit should suffice, though. All we need to
 know is is_padding or not.. But we need to set that bitfield in the
 relay_send_command_from_edge_() call, where the relay cell padding command
 is set. Otherwise the bitfield flag should remain 0.

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