Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

[Davey Song <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> 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
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/dnsop
> > >>
> > >> _______________________________________________
> > >> v6ops mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/v6ops
> > >
> > > _______________________________________________
> > > DNSOP mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>