Thanks for the detailed write-up Mike! Theoretically, moving to QUIC seems great; it seems to solve a lot of problems and has enough advantages that we could just run with it. I'll reiterate some of my primary concerns that I gave in Rome: - I think it would be a mistake to push forward with such a significant change to Tor's transport layer without significant testing and experimentation. We have tools that allow us to do full-network-sized experiments (Shadow), and we have interested researchers that want to help (including me). - However, I am much less optimistic than you that it will just work and instantly improve performance. You mention that Google has done lots of tests, but my guess is they test in environments that look like the Internet - i.e., fast core and slow edges. Do we know how it would perform when the path contains additional 6 edges sandwiching 3 potentially low bandwidth Tor relays? Tor is a significantly different environment than the Internet; for example, an end-to-end congestion signal in Tor will take orders of magnitude longer to reach the client than in traditional networks. - Because of the above, I'm not sure that an end-to-end design is the right way to go. As I mentioned, we have simulators and researchers, so we should be able to learn more and make a more informed decision before committing to a design that will be difficult to change later. - We should be sure to pay close attention to how this will affect emerging networks and applications, e.g., mobile devices and onion services. - The DoS attacks will change form, but I don't think they will disappear. I think it would be wise to understand how DoS might change, which is much easier once we have a design to analyze. Your summary helps with that. I think it would be worth including R&D effort to investigate these issues in any proposal that gets written. Cheers, Rob > On Mar 23, 2018, at 7:18 PM, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote: > > In Rome, I held a session about network protocol upgrades. My intent was > to cover the switch to two guards, conflux, datagram transports, and > QUIC. We ended up touching only briefly on everything but QUIC, but we > went into enough depth on QUIC itself that it was a worthwhile and very > productive session. > > Our notes are here: > https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rome/Notes/FutureTorNetworkProtocolUpgrades > > I wanted to give a bit of background and some historical perspective > about datagram transports for Tor, as well as explain those notes in > long form, to get everybody on the same page about this idea. With > the forthcoming IETF standard ratification of QUIC along with several > solid reference implementations (canonical list: > https://github.com/quicwg/base-drafts/wiki/Implementations), I believe > we are close to the point where we can finally put together a plan (and > a funding proposal) to undertake this work. > > Consider this mail a pre-proposal to temperature check and solicit early > feedback about a Tor-over-QUIC deployment, before we invest the effort > to deep dive into the framing, protocol, and implementation details that > will be necessary for a full proposal.
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev