<p dir="ltr">Hi i am a new partner in tor-dev can you help me te understand the stuffs here<br>
Le 2 août 2019 16:25, "Nick Mathewson" <<a href="mailto:nickm@torproject.org">nickm@torproject.org</a>> a écrit :<br>
><br>
> On Tue, Jun 25, 2019 at 9:24 PM <<a href="mailto:neel@neelc.org">neel@neelc.org</a>> wrote:<br>
> ><br>
> > Hi tor-dev@ mailing list,<br>
> ><br>
> > I have a new proposal: A Tor Implementation of IPv6 Happy Eyeballs<br>
> ><br>
> > This is to implement Tor IPv6 Happy Eyeballs and acts as an alternative<br>
> > to Prop299 as requested here:<br>
> > <a href="https://trac.torproject.org/projects/tor/ticket/29801">https://trac.torproject.org/projects/tor/ticket/29801</a><br>
> ><br>
> > The GitHub pull request is here:<br>
> > <a href="https://github.com/torproject/torspec/pull/87">https://github.com/torproject/torspec/pull/87</a><br>
> ><br>
> > Thank You,<br>
><br>
> Hi, Neel!  Thanks for working on this; I believe it's come a long way<br>
> in the last month!<br>
><br>
> Here are a few questions based on the current PR.<br>
><br>
> * We need to revise the "relay selection changes" to match the<br>
> vocabulary of guard-spec.txt.  It's easy to say "select at least one<br>
> relay with an ipv6 address", but it's not trivial to do so in<br>
> practice.  (Also, do we do this always, or do we do this only when we<br>
> think we can connect to ipv6 addresses?)<br>
><br>
> * We also need to think about what this algorithm means in terms of<br>
> guard-spec.txt's data structures.  Does it mean that each connection<br>
> to a guard is replaced with two?  Does it mean that some of the<br>
> reachability variables are replaced by two?<br>
><br>
> * The proposal considers TCP success vs authentication success as<br>
> indicating that a connection has succeeded. There is a good<br>
> alternative that reduces CPU load, however.  The TLS handshake has<br>
> multiple phases, and the expensive CPU stuff all happens after we<br>
> receive a ServerHello message.  If we treat an incoming ServerHello as<br>
> meaning that the connection will be successful, we can avoid most<br>
> wasted handshakes.<br>
><br>
> [This would definitely not handle the problem where one of a server's<br>
> addresses is correct but the other address is a different server<br>
> entirely, but I hope we can catch that earlier in data flow, possibly<br>
> at the authorities.]<br>
><br>
> * The 1.5 second delay, and associated other hardcore times, should be<br>
> a network parameter, transmitted in the consensus.  1.5 seconds can be<br>
> the default, but we will want to keep the ability to tune it later on.<br>
><br>
> * For pluggable transports, do we want to manage this process<br>
> ourselves, or delegate the decisions to the PT?  Each option has its<br>
> own benefits and risks.<br>
><br>
> cheers,<br>
> -- <br>
> Nick<br>
> _______________________________________________<br>
> tor-dev mailing list<br>
> <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
> <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</p>