Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt
> > This hints at a general misunderstanding on how "The Internet" works. > > Talking to the local ISP on "what would you recommend, IPv4 or IPv6?" > can give an indication, but if the server you're trying to talk to > is on the other side of the world, the local ISP's preference for > IPv4-vs-IPv6 might be the opposite of what actually works better to > reach said server. There are many networks on the path... > > Talking to far-end server need measurement on end-to-end path.So the accurracy of end-to-end measurement is the key. There are acturally lots of practice in the fields of NPM and APM. People can do it well. Davey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt
To get to know the current status of HE , I did a simple test on my handy devices visit top 20 website or open existing apps (currently only DNS). I captured DNS query pairs (intervel less than 10s) and count HE query pairs whoes interval less than 100ms. There is a prelimiary result: 1) My laptop with web browsers (Chrome, firfox, Sogou, QQ, 360). All browers support HE in DNS in which more than 90% query pairs are HE query pairs. 2) My Andriod phone(V7.1.1). 262 query pairs out of 802 pairs . It means only 32.6% DNS queries supported by HE. Not 32.6% Apps on my phone, because some Apps may sent more DNS queries than others. I made a statisitcs on interval of all & A pairs (statistics if no HE pairs included), the average interval is 409ms (534ms), the median delay is 198ms(324ms), and the maximum is 7,135ms. If hostname resolution is not support HE, the connection attampt will also be delayed accrodingly. 3) My ipad (V11.4.1). 1208 & A query pairs out of 1216 pairs. It means more than 99% DNS queries supported by HE. It is true that IOS asynchronous DNS API. But it is unkonwn on how many apps make connection asynchronously. It will be investigated later. In conlusion, HE is not widely supported at least in Android platform. Large companies can invest and implement it for their users. But it is not fair for small Apps providers to endure such competitive disadvantage due to IPv6 deployment. - In general, I wouldn't be excited about placing such complicated >> functionality in the network rather than end hosts. Sometimes it >> may be justified as a least evil option, but the current description >> of the draft didn't fully convince me >> > > Before I put down this draft, I talked with some CPs (content/app > providers) and ISPs, they have motivations and requirement on this. One > example is Tencent, they are planning to deploy a complicated measurement > network to info their Apps (with a SDK ) which address family they should > try first (their apps use dns over http). I'm told that Tencent think HE > implemented on each client is too complicated (they have comlicated apps) > and resource consuming. ISP's motivation is easy to understood, they always > try to improve their network connenctivity on both IPv4 and IPv6. I have no > more comment on your saying of evil option：） Any technology can be used as > evil purpose I think. > Davey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt
Hi, On Tue, Sep 25, 2018 at 10:30:05AM +0800, Davey Song wrote: > Before I put down this draft, I talked with some CPs (content/app > providers) and ISPs, they have motivations and requirement on this. One > example is Tencent, they are planning to deploy a complicated measurement > network to info their Apps (with a SDK ) which address family they should > try first (their apps use dns over http). I'm told that Tencent think HE > implemented on each client is too complicated (they have comlicated apps) > and resource consuming. This hints at a general misunderstanding on how "The Internet" works. Talking to the local ISP on "what would you recommend, IPv4 or IPv6?" can give an indication, but if the server you're trying to talk to is on the other side of the world, the local ISP's preference for IPv4-vs-IPv6 might be the opposite of what actually works better to reach said server. There are many networks on the path... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt
Hi Jinmei, Thanks for your comments. I once had same questions in my mind when this draft is conceived. I reply inline. Some quick observations: > > - I don't see why the intended status is Standards Track. It seems to > be a document about an operational practice rather than a new > protocol feature. > I agree with your observation here if the draft intends to share information and practice. It now goes with Standards Track because the authors would like to provide a new HE feature(or a framework) on network side as a peering funtion of client-side HE. I would like to see more feadback on this issues. - In general, I wouldn't be excited about placing such complicated > functionality in the network rather than end hosts. Sometimes it > may be justified as a least evil option, but the current description > of the draft didn't fully convince me > Before I put down this draft, I talked with some CPs (content/app providers) and ISPs, they have motivations and requirement on this. One example is Tencent, they are planning to deploy a complicated measurement network to info their Apps (with a SDK ) which address family they should try first (their apps use dns over http). I'm told that Tencent think HE implemented on each client is too complicated (they have comlicated apps) and resource consuming. ISP's motivation is easy to understood, they always try to improve their network connenctivity on both IPv4 and IPv6. I have no more comment on your saying of evil option：） Any technology can be used as evil purpose I think. - I suspect the discussion on breaking DNSSEC is way too hand-waving. > In my general understanding it's generally not accepted at dnsop to > justify breaking DNSSEC just by saying "it's okay as validation at > end hosts is not typical". Especially if it really intends to be > published as Standards Track I suspect some more detailed discussion > with a stronger justification will be needed. > Sorry, I admit current txt on breaking DNSSEC is weak. Now it is put into Security Considerations as well as the issues on incoherency. I think one way to avoid it as suggested in Security Considerations is to artificially delay the answers, other than omitting the record and its RRSIG Best regards, Davey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt
At Fri, 21 Sep 2018 14:31:50 +0800, Davey Song wrote: > I just submited a new draft intending to provide better connectivity from > network side function . Comments are welcome. Some quick observations: - I don't see why the intended status is Standards Track. It seems to be a document about an operational practice rather than a new protocol feature. - In general, I wouldn't be excited about placing such complicated functionality in the network rather than end hosts. Sometimes it may be justified as a least evil option, but the current description of the draft didn't fully convince me - I suspect the discussion on breaking DNSSEC is way too hand-waving. In my general understanding it's generally not accepted at dnsop to justify breaking DNSSEC just by saying "it's okay as validation at end hosts is not typical". Especially if it really intends to be published as Standards Track I suspect some more detailed discussion with a stronger justification will be needed. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
