Re: Production-scale NAT64

[Ca By <cb.list6 () gmail com>]

On Thu, Aug 27, 2015 at 5:59 AM, Bjoern A. Zeeb <
bzeeb-lists () lists zabbadoz net> wrote:

> > On 26 Aug 2015, at 15:23 , Ca By <cb.list6 () gmail com> wrote:
> >
> > On Wed, Aug 26, 2015 at 8:16 AM, <Valdis.Kletnieks () vt edu> wrote:
> >
> > > On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
> > >
> > > > Another relevant metric, less than 25% of my mobile subscribers traffic
> > > > require NAT64 translating.  75+% of bits flows through end-to-end IPv6
> > > > (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on
> > > ...).
> > >
> > > So I'm guessing that 75% of the traffic flows with better latency than
> > > the 25% IPvhorse-n-buggy traffic? ;)
> > Facebook says IPv6 is 20-40% faster
> http://www.internetsociety.org/deploy360/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/
> > Another way to look at it, IPv4 is 20-40% slower than IPv6.
>
>
> The question I have not seen the answer yet to is “why?”
>
> Is this really because of the network, e.g., separate pipes in some places
> still, with forwarding devices handling a lot less pps?
>
> Is it because of people having done a newer cleaner-cut network stack
> implementation and lately cared about its performance?
>
> Is it about middle nodes?
>
> Has anyone done the research on this?


I too do not know, and i do not care.

Looking in the rear view mirror at why NAT encumbered IPv4 sucks is not a
priority of mine, but may be an interesting pedantic project for internet
historians.  We know that NAT causes very minor latency (session setup and
matching per packet) and very minor loss (state management chaos), but i
can hardly believe that is a 20-40% speedup. Then again, TCP is a sensitive
thing.

Either way, Twitter and Amazon seem a tad slow... perhaps they should
enable IPv6.  Or maybe they have plenty of IPv4 and don't care much about
the 20-40% performance gain that Facebook has seen.

CB