Re: New passive performance metrics in Tor

[Björn Scheuermann <scheuermann@xxxxxxxxxxxxxxxxxxxxx>]

Dear Nick,

Nick Mathewson wrote:
> Replying here rather than on
> https://trac.torproject.org/projects/tor/ticket/1819 , since this is
> where the discussion of the "bidirectional connection counting"
> feature started.  I'm hoping that BjÃrn and Florien (or somebody who
> knows their work) will point me at some kind of writeup to explain the
> motivation here.  Why is the fraction of "bidirectional" connections
> important?  What does knowing it get us?

sorry for the long delay - I have been out of office for the last few
days.

The background behind this metric is the following: Tor (just like many
other overlay networks) uses many TCP connections over the same physical
link - all incoming/outgoing TCP connections of an OR will typically
share the same physical Internet connection. We found that in such cases
the individual TCP interactions can interact, with potentially severe
performance impact. The short version of the story is as follows:

The outgoing queue of the network interface is shared between all TCP
connections that traverse the respective link. This queue contains both
data segments for outgoing traffic and ACKs for incoming TCP segments.
If there is significant outgoing data traffic, the outgoing ACKs can be
delayed significantly, which impacts TCP's self-clocking and can
severely deteriorate the performance for incoming traffic (simply
because it takes a long time until the ACKs finally make it to the front
of the queue and are transmitted). This causes unnecessary TCP timeouts
and slow starts.

These effects can be avoided with simple traffic shaping mechanisms that
prioritize TCP ACKs in the outgoing interface queue. However, this works
only if the TCP connection transfers data in one direction (i.e., only
incoming traffic or only outgoing traffic, but not both at the same
time). If TCP connections are used bidirectionally, ACKs for incoming
traffic are piggybacked on outgoing data segments and therefore cannot
be prioritized that easily. A possible remedy is to "split up"
bidirectionally used TCP connections into one connection per direction
of communication, so as to avoid ACK piggybacking.

We believe that the described effects could be a significant source of
performance problems in Tor. This is the reason why we are interested in
the "bidirectional traffic on TCP connections" metric, in order to get a
feeling how common bidirectional use of TCP connections in Tor "in the
wild" is.

A more in-depth discussion, including experimental results etc., has
recently been accepted as a paper to this year's IEEE LCN conference
(Marks, Tschorsch, Scheuermann: "Unleashing Tor, BitTorrent & Co.: How
to Relieve TCP Deficiencies in Overlays"). An extended version of this
paper (even more results...) is available as a technical report here: 

http://www.cn.uni-duesseldorf.de/publications/library/Marks2010b.pdf


If you have further questions, please do not hesitate to ask. 


Cheers

BjÃrn (+ Florian)


-- 
Jun.-Prof. Dr. BjÃrn Scheuermann
Mobile and Decentralized Networks Group
Heinrich Heine University
UniversitÃtsstr. 1, D-40225 DÃsseldorf, Germany

Building 25.12, Room 02.42
Tel: +49 211 81 11692
Fax: +49 211 81 11638 
scheuermann@xxxxxxxxxxxxxxxxxxxxx
http://www.cn.uni-duesseldorf.de