IPv6 faster/better proof? was Re: Need /24 (arin) asap

Wed Jun 20 00:32:35 UTC 2018

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 at nanog.org> on behalf of Lee Howard <lee.howard at retevia.net>
Sent: Wednesday, June 13, 2018 7:46 AM
To: nanog at 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 at gmail.com wrote:
> From: Ca By <cb.list6 at 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-and-how.html
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-than-IPv4-Part-1/ba-p/6419

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-board
> 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