Re: [tor-bugs] #12890 [Tor]: Design and implement optimizations for socket write limits

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

#12890: Design and implement optimizations for socket write limits
-----------------------------+--------------------------------
     Reporter:  robgjansen   |      Owner:  robgjansen
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-relay
Actual Points:               |  Parent ID:  #12541
       Points:               |
-----------------------------+--------------------------------

Comment (by yawning):

 Before I forget, since I talked to nickm about this on IRC.  I belive
 there's a possible future improvement here, depending on how expensive the
 TCP_INFO query turns out to be, though someone with more time than I have
 should simulate things.

 The polling frequency should be dynamic on a per socket level, based on
 the state of the TCP connection.

 TCP congestion control at a high level is divided into two phases, Slow
 Start and Congestion Avoidance.

 During slow start, on each ACK that covers new data, the congestion window
 grows by `cwnd += min(N, SMSS)` (Older TCP/IP stacks grew it by SMSS,
 which leads to a misbehaving receiver attack).  Congestion window growth
 here is extremely aggressive, so the discrepancy between our polling and
 the actual congestion window will be quite large and we will end up under-
 utilizing the link's capacity.  This should only happen on relatively new
 connections, connections that are cruddy enough that the retransmission
 timer fires, and after the connection has been idle for a while, but the
 first case affects perceived user responsiveness, so it's worth thinking
 about.

 During congestion avoidance, the congestion window grows by up to SMSS per
 RTT (`cwnd += min(1, SMMS*SMSS/cwnd)` on each ACK that covers
 unacknowledged data).  When in congestion avoidance, our estimate should
 track cwnd fairly closely (at least until loss occurs), so our polling
 interval can be relatively infrequent.  There's likewise potential for
 being clever here and adjusting the polling interval based on the RTT
 estimate.

 The information required to distinguish between these two states is
 readily available (cwnd, ssthresh, and rtt) at least on Linux, so it is
 possible to query such things, so it's mostly a matter of "Is it
 affordable in terms of syscalls".

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