[tor-bugs] #16861 [Tor]: Pad Tor connections to collapse netflow records

[Tor Bug Tracker & Wiki]

#16861: Pad Tor connections to collapse netflow records
-----------------------------+--------------------------
     Reporter:  mikeperry    |      Owner:  mikeperry
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------

Comment (by mikeperry):

 Yawning: I took your comment about gettimeofday() into account, and pushed
 a new commit (to both squashed and squashed2) to change all the places
 where I need high resolution to simply use the tv_sec timeval field
 instead of also calling time(). That way, the new code will be no slower
 than the old code, at least.

 However, as I said on IRC yesterday, I believe this code is independent of
 the circuit scheduler. Not only are we padding at the connection level
 (and only when there are no other packets to send), but we also need to
 pad on a connection long after all circuits are gone from it. I think
 involving circuit information is not right (in addition to being a
 complicated layer coordination issue) for these reasons.

 Your suggestion about making a data structure to compensate for libevent's
 timer paucity is interesting and maybe ultimately the right plan, but
 right now I can't think of anything that won't still max out at 1000
 timers (since I still want to preserve millisecond resolution on actual
 packet delivery). I also worry that this complexity may be a bit error
 prone and fragile. I'd be much happier just giving up, emitting a notice,
 and sending the packet directly from channelpadding_schedule_padding()
 without a timer in the case that we have more than say 50k timers (or
 whatever we think libevent will start breaking at), and optimizing later
 if that actually happens in the wild (which I still think is unlikely at
 our current client load and timeout values).

 It may also be possible that the common case will be even slower as a
 result of this data structure, unless we do something really simple like
 make an array of 1000 smartlists that we can index into based on the
 current millisecond. But even that may end up slower in the common case..

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