In your letter dated Wed, 26 Sep 2018 12:58:30 +1000 you wrote: >I have said before, but don't know if I still adhere to it, but >anyways, here's a question: How *long* do people think a biassing >mechanism like HE is a good idea? > >I used to love HE. I now have a sense, I'm more neutral. Maybe, we >actually don't want modified, better happy eyeballs, because we want >simpler, more deterministic network stack outcomes with less bias >hooks?
In my own implementation of HE, I globally (i.e. across all processes) keep track of the time it takes to establish a TCP connection for individual addresses, and I compute values for IPv4 and IPv6. Conceptually I like the idea that if you know (from past measurements) that it takes 100ms or less to establish a connection, you don't wait for a couple of seconds for an attempt to fail. In addition, instead of trying one address at a time, you can add a new connection attempt when the previous one is still running. All of this provides for a better user experience, at the cost of being less deterministic and masking failures. Note that in my implementation, I select the best address (giving a 30ms preference to IPv6) wait for the expected time for the TCP connection to complete and only if that timer expires, move to the next address. So there is no race. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
