Hi Tim:Â
Thank you so much for replying.Â
I hope to address your questions in detail in this email, as well as posing some questions in the second part regarding some parts that we are less sure of.Â
1. Question of scope. Regarding the question of:Â
It's unclear whether your proposal is to:Â
* replace Tor's client to relay and relay to relay TCP links with QUIC, or
* allow Tor to carry arbitrary IP traffic, in addition to streams via a SOCKS proxy.
We will definitely replace relay-to-relay TCP links with QUIC. And we will probably also replace the client-to-proxy link as well but without allowing arbitrary IP traffic (for reasons described in your email). We will still have the SOCKS proxy abstraction as it is right now but intercepting and running on QUIC instead of TCP. Now, I think most of our gain is going to be from the relay-to-relay links but we might be surprised by the reduction in circuit setup latency (as a result of fast QUIC handshakes). So, for the question of prioritization, we will examine relay-to-relay connections first.Â
2. Question of goals and uniqueness. Regarding the question of:Â
Some of the issues your proposal describes are addressed by tor's circuitmux implementation, and by the KIST scheduler implementation.
http://www.cypherpunks.ca/~iang/pubs/ewma-ccs.pdf
http://www.robgjansen.com/publications/kist-sec2014.pdf
Another answer may be that TCP is a proven technology that works acceptably well for the Tor use case. It has a number of cross-platform implementations, stable interfaces, and decent security properties.
I think the KIST paper is really a study that improves over the EWMA scheme, with the additional consideration for egress kernel queuing "fairness". But I think these two papers are really on a different level from our goal. The problems we set out to address are:Â
- Head-of-the-line blocking problem introduced by multiplexing multiple independent circuits over a single TCP stream.Â
- Better congestion control, or decoupling the congestion control from the transport layer.Â
- Explore the benefits of fast handshake and setup time.Â
- Explore security differences between QUIC's TLS-over-UDP and the current TOR implementation. I know this is most likely not going to be very beneficial based on the end-to-end security requirement of TOR right now but this gives a different (and perhaps better) option of doing things.Â
QUIC is specifically designed to tackle the HOL blocking problem when multiplexing multiple flows on a single connection. See
design doc on "Multiplexing".Â
Also, QUIC has a pluggable congestion control, meaning that we can "tailor-make" the congestion control mechanism based on the application.Â
Note that the KIST algorithm can still be applied with our changes to the transport layer. The application scheduling algorithms will not see this change. However, the EWMA algorithm might not be applicable anymore because with QUIC, there is no TCP multiplexing anymore.Â
Finally, we are perfectly aware of the state that QUIC is in right now and are not aiming to replace TCP in production code base overnight. Our goal is to simply examine the benefits of QUIC and contribute to the understanding of some of the problems of TOR over TCP. Maybe that one day under a more suitable circumstance, our project can be useful to the improvement of TOR.Â
Here is a question that we have about security:Â
Since QUIC comes with a transport layer security, we are worried that this feature is conflicting with TOR's application layer security. By "conflicting", I don't mean the QUIC will sabotage TOR's security, but it might be doing redundant work, such as encrypting twice unnecessarily (once for QUIC's TLS and once for TOR). So, we are exploring the possibility of turning off this feature in QUIC. What do you think of this problem? Are we on the right track?Â
Thank you!Â
Li.Â