Sections 3 and 6 of the Quux paper have some relevant discussion [1]
> Unfortunately, it appears that the Quux QUIC paper studied QUIC at the
> wrong position - between relays, and the QuTor implementation is
> unclear. This means that it may still be an open question as to if
> QUIC's congestion
Mike Perry:
> 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
Rob Jansen:
> 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
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 s
I would like to add and advocate that, whatever a network protocol
upgrade will be done, Tor should starts supporting NAT traversal for
it's relay, enabling users to contribute also without a "public ip
address" .
Enabling NATted users to become Tor Relay would increase the baseline of
contributor
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 ses
