Although the FB link is vague but argument itself is true. We just became more intelligent in deploying IPV6. The same measurement if was done in less than a decade for example would show that ipv4 is faster. The dual stack implementation and the slowness introduced by Teredo Tunneling were the main reasons and now we are getting smarter having it deprecating https://labs.ripe.net/Members/gih/examining-ipv6-performance https://tools.ietf.org/html/rfc6555 https://tools.ietf.org/html/rfc7526 Things change, Ipv6 response is showing better has IPV4 is having more TCP re-transmission which the culprit is still not known ( need more analysis) but fingers are pointing to the exhaustion of the ipv4 address so basically CGN , load-balancers and address sharing. Although we can not eliminate peering links and Firewalls. Yet if we have exactly the same topology and traffic crossing the links et Firewalls locations/policies. Analysis didnot confirm why it would have rather more harm on ipv4 than 6 Brgds, LG ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Lee Howard <lee.howard@retevia.net> Sent: Wednesday, June 13, 2018 7:46 AM To: nanog@nanog.org Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On 06/11/2018 05:16 PM, Scott Weeks wrote:
--- cb.list6@gmail.com wrote: From: Ca By <cb.list6@gmail.com>
Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6
And Akaimai reports 80% of mobiles And they both report ipv6 is faster / better.
Let me grab a few more for you: https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why... Preparing for IPv6-only mobile networks: Why and How - The ...<https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html> blogs.akamai.com Apple's upcoming App Store submission requirement around supporting IPv6-only environments (announced last year at WWDC and being enforced starting June 1) has been getting plenty of recent coverage. iOS application developers already need to make sure their applications work in... https://blogs.akamai.com/2016/10/ipv6-at-akamai-edge-2016.html https://www.theregister.co.uk/2016/07/28/ipv6_now_faster_a_fifth_of_the_time which cites an academic paper http://dl.acm.org/citation.cfm?doid=2959424.2959429 by Vaibhav Bajpai and Jürgen Schönwälder https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-kahn/ https://community.infoblox.com/t5/IPv6-CoE-Blog/Can-IPv6-Rally-Be-Faster-tha... https://www.nanog.org/meetings/abstract?id=2281
I'd sure like to see how they came up with these numbers in a technically oriented paper. Most of the above links explain how they got the numbers. Facebook, in particular, did A/B testing using Mobile Proxygen, which is to say that they configured their mobile app to report performance over both IPv4 and IPv6 from the same handset at the same time. Others, including APNIC's https://stats.labs.apnic.net/v6perf have a browser fetch two objects with unique URLs, one from an IPv4-only server and one from an IPv6-only server, and compare them.
There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols.
From time to time somebody says, "Okay, maybe it works in practice, but does it work in *theory*?" Busy engineers hardly ever investigate things going inexplicably right. My hypothesis is that the observed difference in performance relates to how mobile networks deploy their transition mechanisms. Those with a dual-stack APN take a native path for IPv6, while using a CGN path for IPv4, which, combined with the Happy Eyeballs head start, might add 501microseconds, which is a ms, which is 15% of 7ms. Those with an IPv6-only APN use a native path for IPv6, while using either a NAT64 for IPv4 (identical performance to CGN) or 464xlat, which requires translation both in the handset and the NAT64; handsets may not be optimized for header translation. However, I have a dozen other hypotheses, and the few experiments I've been able to run have not confirmed any hypothesis. For instance, when one protocol is faster than another on a landline network, hop count is not a correlation (therefore, shorter paths, traffic engineering, etc., are not involved). Lee
Hmm... Faster and better?
The links seem to be an IPv6 cheerleader write up. I looked at the URLs and the URLs one pointed to and pulled out everything related to IPv6 being faster/better.
Akamai URL:
"For dual-stacked hostnames we typically see higher average estimated throughput over IPv6 than over IPv4. Some of this may be due to IPv6-connected users being correlated with better connectivity, but over half of dual-stacked hostnames (weighted by daily bytes delivered) have IPv6 estimated throughput at least 50% faster than IPv4, and 90% of these hostnames have the IPv6 estimated throughput at least 10% faster than IPv4."
FB URL:
"People using Facebook services typically see better performance over IPv6..."
and it points to https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-bo... which says:
"We’ve long been anticipating the exhaustion of IPv in favor of the speed and performance benefits of IPv6."
"We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6."
I'd sure like to see how they came up with these numbers in a technically oriented paper. There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols.
scott