[tor-bugs] #12889 [general]: Simulate global circuit scheduling from #9262

[Tor Bug Tracker & Wiki]

#12889: Simulate global circuit scheduling from #9262
----------------------------+------------------------
     Reporter:  robgjansen  |      Owner:  robgjansen
         Type:  task        |     Status:  new
     Priority:  normal      |  Milestone:
    Component:  general     |    Version:
   Resolution:              |   Keywords:  Shadow
Actual Points:              |  Parent ID:  #12541
       Points:              |
----------------------------+------------------------

Comment (by robgjansen):

 (Second try, after I lost my first long and detailed explanation to trac.)

 I ran a set of experiments varying the three parameters. The graphs
 showing the results are attached in parts due to file upload size limits.
 (I accidentally attached them to #12541.)

 highwater:
 [https://trac.torproject.org/projects/tor/attachment/ticket/12541/cmux-
 highwater.shadowtor.pdf.xz-part0 part0]
 [https://trac.torproject.org/projects/tor/attachment/ticket/12541/cmux-
 highwater.shadowtor.pdf.xz-part1 part1]
 lowwater:
 [https://trac.torproject.org/projects/tor/attachment/ticket/12541/cmux-
 lowwater.shadowtor.pdf.xz-part0 part0]
 [https://trac.torproject.org/projects/tor/attachment/ticket/12541/cmux-
 lowwater.shadowtor.pdf.xz-part1 part1]
 maxflush:
 [https://trac.torproject.org/projects/tor/attachment/ticket/12541/cmux-
 maxflush.shadowtor.pdf.xz-part0 part0]
 [https://trac.torproject.org/projects/tor/attachment/ticket/12541/cmux-
 maxflush.shadowtor.pdf.xz-part1 part1]

 I compressed and split the PDF files like
 {{{
 xz cmux-highwater.shadowtor.pdf
 split -b 2500K -a 1 -d cmux-highwater.shadowtor.pdf.xz cmux-
 highwater.shadowtor.pdf.xz-part
 }}}
 They can be reconstructed like
 {{{
 cat cmux-highwater.shadowtor.pdf.xz-part0 cmux-highwater.shadowtor.pdf.xz-
 part1 > cmux-highwater.shadowtor.pdf.xz
 xz -d highwater.shadowtor.pdf.xz
 }}}

 The results indicate that the combination of settings that I tested do not
 result in improved download times without decreasing network throughput.
 These findings are consistent with the testing of our global scheduling
 prototype that we performed for the KIST paper.

 The issue here is that we are missing the kernel/tcp information (#12890)
 to help us make intelligent decisions about which channels should get data
 and which ones should not. Without that information, the best approach
 seems to be the greedy one where the scheduler immediately sends as much
 as it can to each channel in an attempt to maximize throughput. Of course,
 this means the circuit scheduler is having little effect, and Tor will not
 be able to prioritize low EWMA circuits over high EWMA circuits correctly
 - the reason for doing this in the first place.

 In our KIST work, we also found that global scheduling alone did not
 improve things dramatically. The real performance benefits were realized
 after doing BOTH the global scheduling AND the socket write limits parts
 of KIST (#12890) - the approaches work hand-in-hand to intelligently set
 the high watermark for each channel. I expect similar results here.

 We can either merge this branch and use the settings that result in the
 old bahavior until #12890 is completed, or we can wait until #12890 is
 completed on top of this branch and we have more simulation results.

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