Hi George, Actually the idea of NHE is inspired partially by CDN stuff, which involve lots of measurments and route users to visit a best path against network dynamics. It proves to be a good practice for morden Internet. No doubt. I'm wondering CDN is also breaking DNSSEC to stub-resolver, right?
Davey On Wed, 26 Sep 2018 at 13:28, George Michaelson <g...@algebras.org> wrote: > I'm not speaking for Owen. I'm speaking for myself. I asked a > question. Is this really a long-term defensible thing to do? Do we > want HE forever? > > run a race? thats fine. But, as the thread here notes, the > second-by-second conditions which leads one TCP to return SYN-ACK > before another can be volatile. > > run a race, but bias the race towards the one you like? okaaaay.. But > once we're beyond a world where the V6 needs the bias, for anyone > stuck on the vestigial 4-is-better space, this means they incurred > *additional* connection penalty. wheres the control knob? > > now we're talking about tuning the bias, weighting the sum, tumbling > the dice. I thought it was a crap shoot anyway... > > -G > On Wed, Sep 26, 2018 at 3:24 PM Joe Abley <jab...@hopcount.ca> wrote: > > > > What better idea did you mean? > > > > Being able to select a protocol based on what works best for the > > end-user does not seem like a terrible end-state for the end-user, > > short- or long-term. > > > > > On Sep 25, 2018, at 21:25, Owen DeLong <o...@delong.com> wrote: > > > > > > It was never a good idea. It was a necessary evil (kind of like NAT in > that regard) to expeditiously deal with a somewhat tenacious (at the time) > problem which has since been given a significantly better solution, but so > long as the workaround appears to be working, people are loathe to put in > the effort of implementing the actual solution. > > > > > > sigh… Human nature. > > > > > > Owen > > > > > > > > >> On Sep 25, 2018, at 19:58 , George Michaelson <g...@algebras.org> > 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? > > >> > > >> * is it a good idea *forever* > > >> > > >> * or is it a transition path mechanism which has an end-of-life? > > >> > > >> * how do we know, when its at end-of-life? > > >> > > >> 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? > > >> > > >> I barely register if I an on v4 any more. I assume I'm on 6 on many > > >> networks. This is as an end-user. I guess if I am really an end user, > > >> this belief I understand TCP and UDP is false, and I should stop > > >> worrying (as an end user) > > >> On Wed, Sep 26, 2018 at 12:49 PM Davey Song <songlinj...@gmail.com> > wrote: > > >>>> > > >>>> But in the general case the network cannot. > > >>>> Think host multi-homing. > > >>> > > >>> > > >>> Yes or no. > > >>> > > >>> Generally speaking the races of IPv6 and IPv4 connections on both > network and client are going to be suffered by netowrk dynamics, including > Multi-homing, route flaps, roaming, or other network falilures. Extremely, > a client can get a better IPv6 connection in one second (when IPv6 win the > race), and lose it in next second. In such case, more sophisticated > measurement should be done(on client or network) , for a longer period, on > statistics of RTT and Failure rate, or combinations of them. But in IMHO, > the assumption of HE is relatively stable network for short exchange > connections. The dynamics exits but relatively rare or no notable impact on > HE. So I see no such discussion in RFC8035. > > >>> > > >>> Davey > > >>> _______________________________________________ > > >>> DNSOP mailing list > > >>> DNSOP@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dnsop > > >> > > >> _______________________________________________ > > >> v6ops mailing list > > >> v6...@ietf.org > > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > > _______________________________________________ > > > DNSOP mailing list > > > DNSOP@ietf.org > > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
