Re: [tor-bugs] #3630 [Tor Relay]: Reduce token bucket refill interval

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#3630: Reduce token bucket refill interval
-------------------------+--------------------------------------------------
 Reporter:  Flo          |          Owner:     
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:     
Component:  Tor Relay    |        Version:     
 Keywords:               |         Parent:     
   Points:               |   Actualpoints:     
-------------------------+--------------------------------------------------

Comment(by Bjoern):

 Thanks for the comments.

 Replying to [comment:2 arma]:
 > Profiling fast Tor relays in the past showed that they spent 5-10% of
 their cpu time refilling buckets.
 > If we refill buckets 100 times as often, will we spend 90% of our cpu
 time refilling buckets?

 We implemented this, played a lot with different refill intervals, and
 explicitly assessed the CPU load on our own relay. We didn't notice any
 impact on the server load. (And after all, why should there be any?
 Refilling buckets is a trivially simple operation...)

 That doesn't mean that it wouldn't be worth looking at this again - do you
 have a pointer to the results that you mention?

 > Also, are we removing any realistic chance that we would flush more than
 one cell at once? If MTUs are often 1500, sending a second cell could be
 much cheaper than the earlier analysis implies.

 Apparently you are implying that everything flushed to a TCP socket will
 immediately be sent. This is, in general, not the case, as TCP's
 congestion and flow control comes into play (as well as the queue
 management algorithms of the specific TCP implementation). As soon as the
 network path capacity is (nearly) used, a queue will build up at the TCP
 layer and the problem will solve itselve, as TCP will then have enough
 data in its queue to build large segments. If the capacity is not used -
 well, there's no problem in this case.

 In any case, today's TCP implementations are quite clever about building
 suitable segments. There's no need for us to mess with that.

 Again, though, we could do a practice check and see whether we see
 significant differences in the sizes of the TCP segments that an onion
 router generates if we reduce the refill interval.

 > That's not to mean we shouldn't make a change like this. But it would be
 great to better understand what results we expect to see, so we can check
 to make sure that we actually see them.

 I think we already made quite some progress in that direction, in the
 context of ticket #2536 (where this one here is coming from). We built a
 simulation model of Tor and ran network simulations (with ns-3), we
 performed real-world lab measurements in the context of TCP behavior in an
 onion routing setting, and we also did real-world measurements on an
 active onion router with various changes in the context of cell queueing
 and bandwidth management.

 Nevertheless, we'll definitely look at the points that you raise once
 again. To this end, a pointer to the profiling results that you mention
 would really be very helpful (because they appear to heavily contradict
 our own results).

 Thanks again!

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