[tor-bugs] #9166 [Tor]: Write a UTP-based channel implementation

[Tor Bug Tracker & Wiki]

#9166: Write a UTP-based channel implementation
---------------------------+------------------------------------------------
 Reporter:  nickm          |          Owner:                  
     Type:  defect         |         Status:  new             
 Priority:  normal         |      Milestone:  Tor: unspecified
Component:  Tor            |        Version:                  
 Keywords:  tor-relay utp  |         Parent:  #9165           
   Points:                 |   Actualpoints:                  
---------------------------+------------------------------------------------

Comment(by robgjansen):

 Replying to [comment:10 karsten]:
 > I just finished new Shadow simulations using the large 64 GB network
 configuration.  See attached two PDFs:
 >
 >  -
 [https://trac.torproject.org/projects/tor/attachment/ticket/9166/sjm217
 -utp-64GB-seeds-combined.pdf sjm217-utp-64GB-seeds-combined.pdf] compares
 two runs with uTP for none of the links to two runs with uTP for all
 links.  The two runs using the same configuration use different random
 seeds (using `scallion` vs. `scallion -s 2`).  The motivation for this
 experiment was to see if the large 64 GB network configuration shows more
 significant performance differences than the small 16 GB network
 configuration, and to see if differences are real or random.
 Unfortunately, it looks like differences are mostly random.
 >

 Yeah, it definitely doesn't *look* like the experiments actually used a
 different transport.

 >  -
 [https://trac.torproject.org/projects/tor/attachment/ticket/9166/sjm217
 -utp-64GB-traffic-combined.pdf sjm217-utp-64GB-traffic-combined.pdf]
 compares the runs with seed 1 to similar runs that put additional non-Tor
 TCP traffic on the Shadow network.  Additional TCP traffic is produced by
 adding a second instance of Shadow's filetransfer plugin called traffic,
 making all clients perform requests to fileservers directly, and removing
 all `".*[traffic-.*"` lines from `scallion.log` before making graphs.  The
 motivation for this experiment was to see if additional network load has
 any effect on Tor performance.  Looks like this is not the case.
 >

 I wouldn't expect it to produce the results you want, unless you produce
 the extra TCP load on relays, clients, or fileservers that are bottlenecks
 -- you need to 'steal' bandwidth from the client's Tor application, or
 from a relay's Tor application. You could do this by adding the extra
 client applications on existing Tor client nodes, and then reduce their
 bandwidth to ensure the extra load means less bandwidth for Tor.

 > I'd like to do one more experiment: can Shadow somehow output what
 amount of traffic uses TCP vs. UDP?  I'd like to re-run the simulation in
 a small or tiny network with uTP enabled and disabled, to confirm that
 enabling/disabling uTP actually worked.  Rob, any idea how Shadow could
 provide this information?

 Its your lucky day ;) It wasn't directly possible, but I just implemented
 and pushed it to shadow master. You need to include 'socket' in the
 attribute value of the 'heartbeatloginfo' attribute to the 'node' element.
 So, something like this:

 {{{
 <node heartbeatloginfo="node,ram,socket" ... >
 }}}

 Careful though, as this prints out information for every active socket for
 every node on which you enable this feature. grep the logs for '\[shadow-
 heartbeat\] \[socket'.

 If you are feeling particularly adventurous, you can enable for every node
 in the simulation at the same time with the shadow command line switch:

 {{{
 scallion --heartbeat-log-info=node,ram,socket ...
 }}}

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