[tor-dev] DefenestraTor: Throwing out Windows in Tor

[Mike Perry]

Thus spake Roger Dingledine (arma at mit.edu):

> http://www.cacr.math.uwaterloo.ca/techreports/2011/cacr2011-06.pdf
> 
> To reduce congestion, we first evaluate small fixed-size circuit win-
> dows and a dynamic circuit window that adaptively resizes in response to
> perceived congestion. While these solutions improve web page response
> times and require modification only to exit routers, they generally
> offer poor flow control and slower downloads relative to Tor's
> current design.To improve flow control while reducing congestion,
> we implement N23, an ATM-style per-link algorithm that allows Tor
> routers to explicitly cap their queue lengths and signal congestion
> via back-pressure. Our results show that N23 offers better congestion
> and flow control, resulting in improved web page response times and
> faster page loads compared to Tor's current design and the other
> window-based approaches. We also argue that our proposals do not enable
> any new attacks on Tor users' privacy.

Great stuff!

So to summarize, they took the reduced circwindow stuff we've already
tried out, improved it to make it dynamic, and then found something
still better (N23). 

It also looks like they've reproduced the fact that the circwindow
changes weren't significantly better than stock tor on a more tor-like
simulator (ModelNet), which we observed during our tests. That's
great: it gives a good confidence boost to results from ModelNet.
Hopefully this means the simulator is good enough so that N23 really
is better for live tor. 

According to Appendix A, it also looks like if we use N23, we won't
need ewma? I wonder what this means for an orconn-level ewma.. Is N23
supposed to be the solution to all our fairness problems? I don't see
any statements about the simulation setup used for Appendix A, either.
Is it still their full ModelNet setup?

Perhaps we should work with them to hook up a full Torperf setup to
this, and/or document a proper standard Tor simulator and evaluation
framework.

Overall, I'm very excited. If we can manage to try out both the
optimistic data patch and N23 in 0.2.3.x (independent of eachother, of
course), tor might actually be usably fast ;).

 
-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110313/f05465c9/attachment.pgp>