Having a predictable bias seems better than an unpredictable one. > On Sep 25, 2018, at 22: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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
