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

["STARK, BARBARA H" <[e-mail]>]

Hi Davey,
Thanks for the info. That’s enlightening.
I would not support this as either a standard or a best practice. The proposed NHE mechanism appears to be a capability only of interest to ISPs in countries/regions where (because of how they have chosen to set up their IPv6 peering) they are impacted by the actions of specific transit providers (and other ISPs) doing bad IPv6-related things; and hosts aren’t doing HE. I would be fine with something informative along the lines of “if an ISP finds itself in this situation, here is a work-around they might consider doing, as a last resort (after futilely trying to get the underlying causes fixed or trying to ensure multiple transit paths are available)”. Designing a network with a single point of failure is never a good idea. But the preferred approach should be to recommend connecting to multiple IPv6 peers, rather than using IPv4 as the backup to failure of a single IPv6 peer.

The map makes this problem look very regional, national, or even company-specific. I don’t think it’s a good idea to create standards or best practices for work-arounds to regional/national/company-specific problems.

I did see the email from Tony pointing to problems inside the US and Europe. But they don’t seem impactful enough for ISPs in these regions to be wanting to do this sort of work-around.
Barbara

From: Davey Song <[e-mail]>
Sent: Wednesday, September 26, 2018 11:10 PM
To: STARK, BARBARA H <[e-mail]>
Cc: Tony Finch <[e-mail]>; Gert Doering <[e-mail]>; dnsop <[e-mail]>; [e-mail]
Subject: Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

Hi Barbara,

Thanks for your comments and sharing. I need to note that NHE is not competing with
Client-side HE or competing with deployment of fully functioning IPv6. The background of
NHE is :

1) the dualstack is real. Client is facing the choice ipv4 or ipv6.
2) the poor or unpredictable IPv6 performance is real (https://stats.labs.apnic.net/v6perf<https://urldefense.proofpoint.com/v2/url?u=https-3A__stats.labs.apnic.net_v6perf&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=UClJsJsCXhi0G8zfGtyd-jc6xlVyeP-pDfD9cuU89OU&s=ciUdcpoxV8G6M_g6RNYgM_3VzGft9mc2TVlGm3EQKy0&e=> ).
3) Low adoption of Client-side HE is realy.

So the suffering of users is real in dualstack.

What we are trying to do is to make the dualstack less painful for users in these regions.
We can not say "you are starving or poor becuase you are not rich". We can not jump
directly to build a fully functioning IPv6 in one day (like roma city). I feel so sad the region
I live failed to catch up the average level of IPv6 development. But it is true the IPv6
development situation varies in different places.

Maybe your observation is true that local ISP is the major source of broken IPv6. However,
though I'm not network operator, I had at least two observations of IPv6 failure caused
by far-end and midst. One case is a real user complaint from China telecom. It proved
that user experinced long delay when Servfail is received when asking AAAA for many times.
It is the problem of authoritative of that site.Another case is a real routring problem of my office
which lasts for two days due to the middle transit (Hurricane Electric) not acept my
company's prefix. There are other cases may introduced by my co-author who have
more experince run ipv6 network.

Maybe you (and other guys) missed that the most important argument in this draft is if HE is
not widely deployed, NHE can enable ISP to deloy it and gain.

As for CDN statements made in this thread: CDNs are in the business of optimizing connections to their content. HE isn't about optimizing connections -- it's about more quickly reacting to the likelihood of outright brokenness. But it sounds like NHE *is* about optimizing (where IPv6 isn't broken, but is just really slow)? I'm a bit confused about this.

As to this question,  NHE does the same thing HE did racing the IPv6 and IPv4 connections to avoid both broken and slow IPv6. But NHE does optimizing as well in terms of stopping sending additional traffic if IPv6 connection is slow (not broken) , becuase AAAA record will not be recieved or AAAA record is received too late (one promising direction for next version of NHE draft).

Davey