Mailing List Archive

On 11/27/21 02:41, Michael Thomas wrote:

> Amazon's in this case. They are monetizing their lack of v6 support
> requiring you go through all kinds of expensive hoops instead of doing
> the obvious and routing v6 packets.
>

Individual CDN's and content providers have better control over how they
deploy IPv6, vs. ISP's who have far less capital, warm bodies and
innovation DNA.

I'm arguing for the latter.

Mark.

On 11/26/21 23:47, Jean St-Laurent via NANOG wrote:

> With that specific line directly from Apple:
>
> "And when IPv6 is in use, the median connection setup is 1.4 times
> faster than IPv4. This is primarily due to reduced NAT usage and
> improved routing."
>
> There it is, Improved routing.
>

Perhaps you mean "improved forwarding".

In an environment that is heavily peered, what is the visual difference
in experience for a customer connecting to a site at 1ms vs. 1.4ms?

Across the sea, assume 140ms between Cape Town - London (Omicron,
anyone?), what is the visual difference between 140ms vs. 196ms? Okay,
bad example, but I can probably get an MS-MPC from Juniper that can claw
back 1.3X of that 1.4X advantage :-). Besides, locally-peered traffic is
likely to exceed long-haul traffic, in many markets.

Mark.

On 11/27/21 02:15, Jean St-Laurent via NANOG wrote:

> We now have apple and fb saying ipv6 is faster than ipv4.
>
> If we can onboard Amazon, Netflix, Google and some others, then it is
> a done deal that ipv6 is indeed faster than ipv4.
>
> Hence, an easy argument to tell your CFO that you need IPv6 for your CDN.
>

Could work for CDN's... but what about the CFO of an ISP or MNO?

Mark.

On 11/27/21 02:39, Jean St-Laurent via NANOG wrote:

> But CFOs like monetization. Was that thread about IPv6 or CFO?
>

In 2021, what's the difference?

Mark.

Mark Tinka wrote:

> I can very easily see why "IPv6 saves you on CG-NAT capex might not
> be entirely true" in cases such as these.

Because lengthy IPv6 addresses mean a lot more opex than IPv4.

> On paper, it all adds up.

With IPv6, you need 4 times more paper.

Masataka Ohta

On Fri, Nov 26, 2021 at 6:51 PM Oliver O'Boyle <oliver.oboyle@gmail.com>
wrote:

> They're getting better at it, at least. They also recently added v6
> support in their NLBs and you can get a /56 for every VPC for direct
> access. I don't think they offer BYO v6 yet, as they do for v4, but it will
> come.
>

Since we are deploying BYO IPv6 in AWS, I can assure you they do offer it
now. That was a blocker for us.

Scott

On 11/27/21 17:07, Masataka Ohta wrote:

> Because lengthy IPv6 addresses mean a lot more opex than IPv4.

I disagree - it can be more opex if you want to run both together, but
less so if you choose one; largely IPv6, but also largely IPv4 if you
don't intend to be in the game for the rest of your life.

My point was that there might not obviously be a linear relationship
between less CG-NAT and more native IPv6, that makes a material
difference to the CFO's Excel spreadsheet, off the bat.

Mark.

On Sat., Nov. 27, 2021, 10:46 Scott Morizot, <tmorizot@gmail.com> wrote:

> On Fri, Nov 26, 2021 at 6:51 PM Oliver O'Boyle <oliver.oboyle@gmail.com>
> wrote:
>
>> They're getting better at it, at least. They also recently added v6
>> support in their NLBs and you can get a /56 for every VPC for direct
>> access. I don't think they offer BYO v6 yet, as they do for v4, but it will
>> come.
>>
>
> Since we are deploying BYO IPv6 in AWS, I can assure you they do offer it
> now. That was a blocker for us.
>

Wonderful! When did they start offering that?



> Scott
>

On Sat, Nov 27, 2021 at 5:05 PM Oliver O'Boyle <oliver.oboyle@gmail.com> wrote:

> On Sat., Nov. 27, 2021, 10:46 Scott Morizot, <tmorizot@gmail.com> wrote:
>> Since we are deploying BYO IPv6 in AWS, I can assure you they do offer it now. That was a blocker for us.

> Wonderful! When did they start offering that?

I believe it was announced back in the first half
of 2020.

As I recall it was limited to certain regions at the
time of the original announcement (and being
AWS it probably still has some region and/or
resource specific availability limitations).

On 11/27/21 7:46 AM, Scott Morizot wrote:
> On Fri, Nov 26, 2021 at 6:51 PM Oliver O'Boyle
> <oliver.oboyle@gmail.com> wrote:
>
> They're getting better at it, at least. They also recently added
> v6 support in their NLBs and you can get a /56 for every VPC for
> direct access. I don't think they offer BYO v6 yet, as they do for
> v4, but it will come.
>
>
> Since we are deploying BYO IPv6 in AWS, I can assure you they do offer
> it now. That was a blocker for us.
>
I thought it had to be some virtual private cloud setup? To get the long
tail it needs to be a lot more simple. Like "here is the AAAA record"
after autoconf.

Mike

> On Nov 27, 2021, at 06:04 , Mark Tinka <mark@tinka.africa> wrote:
>
>
>
> On 11/27/21 02:41, Michael Thomas wrote:
>
>> Amazon's in this case. They are monetizing their lack of v6 support requiring you go through all kinds of expensive hoops instead of doing the obvious and routing v6 packets.
>>
>
> Individual CDN's and content providers have better control over how they deploy IPv6, vs. ISP's who have far less capital, warm bodies and innovation DNA.
>
> I'm arguing for the latter.
>
> Mark.

I honestly think that in Amazon’s case, it’s because they’ve cocked up v4 so badly in their attempts to squeeze every drop of life out of every v4 address they have that they have built a nightmare network that makes it utterly difficult to do the obvious and simply route v6 packets because they can’t even do that with v4 if they wanted to.

Admittedly, this is based only on comments and descriptions I’ve heard from others about the Amazon network, including customers, Amazon SEs, Amazon staff, etc., but it does seem to fit the available observations rather well.

Owen

> On Nov 27, 2021, at 06:05 , Mark Tinka <mark@tinka.africa> wrote:
>
>
>
> On 11/27/21 02:15, Jean St-Laurent via NANOG wrote:
>
>> We now have apple and fb saying ipv6 is faster than ipv4.
>>
>> If we can onboard Amazon, Netflix, Google and some others, then it is a done deal that ipv6 is indeed faster than ipv4.
>>
>> Hence, an easy argument to tell your CFO that you need IPv6 for your CDN.
>
> Could work for CDN's... but what about the CFO of an ISP or MNO?
>
> Mark.

Shouldn’t the argument that we can reduce our CGN spend by 50-80% work there?
Especially when you couple it with the argument that IPv6 deployment will likely reduce CGN related support calls which are one of the
biggest expenses for most ISP/MNOs?

Owen

> On Nov 27, 2021, at 06:05 , Mark Tinka <mark@tinka.africa> wrote:
>
>
>
> On 11/27/21 02:39, Jean St-Laurent via NANOG wrote:
>
>> But CFOs like monetization. Was that thread about IPv6 or CFO?
>
> In 2021, what's the difference?
>
> Mark.

Even in 2021, one improves network capabilities while the other counts beans.

Which is which is left as an exercise to the reader.

Owen

On Sat., Nov. 27, 2021, 13:34 Michael Thomas, <mike@mtcc.com> wrote:

>
> On 11/27/21 7:46 AM, Scott Morizot wrote:
>
> On Fri, Nov 26, 2021 at 6:51 PM Oliver O'Boyle <oliver.oboyle@gmail.com>
> wrote:
>
>> They're getting better at it, at least. They also recently added v6
>> support in their NLBs and you can get a /56 for every VPC for direct
>> access. I don't think they offer BYO v6 yet, as they do for v4, but it will
>> come.
>>
>
> Since we are deploying BYO IPv6 in AWS, I can assure you they do offer it
> now. That was a blocker for us.
>
> I thought it had to be some virtual private cloud setup? To get the long
> tail it needs to be a lot more simple. Like "here is the AAAA record" after
> autoconf.
>
Well, VPC is the only deployment model now. EC2 Classic is long gone
(though some long-time legacy customers may still have it as an option). If
you create an account, you get a default VPC. You can use it or create
another with a few clicks. Prefixes get assigned upon creation but you can
add more afterwards. It's actually pretty straightfoward. Setting up basic
DNS in Route53 is also pretty straightforward. There are no real barriers
up to this point.

> Mike
>

On Sat., Nov. 27, 2021, 12:59 Gary Buhrmaster, <gary.buhrmaster@gmail.com>
wrote:

> On Sat, Nov 27, 2021 at 5:05 PM Oliver O'Boyle <oliver.oboyle@gmail.com>
> wrote:
>
> > On Sat., Nov. 27, 2021, 10:46 Scott Morizot, <tmorizot@gmail.com> wrote:
> >> Since we are deploying BYO IPv6 in AWS, I can assure you they do offer
> it now. That was a blocker for us.
>
> > Wonderful! When did they start offering that?
>
> I believe it was announced back in the first half
> of 2020.
>
> As I recall it was limited to certain regions at the
> time of the original announcement (and being
> AWS it probably still has some region and/or
> resource specific availability limitations).
>

Likely. But if it was announced in 2020 then the rollout is either
complete, or mostly complete, by now.

>

On Fri, Nov 26, 2021 at 3:07 PM Michael Thomas <mike@mtcc.com> wrote:
>> On 11/26/21 1:44 PM, Jean St-Laurent via NANOG wrote:
>> Here are some maths and 1 argument kicking ass pitch for CFO’s that use iphones.
>> Apple tells app devs to use IPv6 as it's 1.4 times faster than IPv4

> This really hits my bs meter big time.

If I had to guess, this is an example of correlation is not causation.
Folks with IPv6 tend to be on savvier service providers who have
better performance for both IPv4 and IPv6. To find out for sure,
you'd have to do an experiment where same-user-same-server connections
are split between IPv4 and IPv6 and then measure the performance
difference. I don't know if anyone has done that but these particular
articles look like someone is just looking at the high-level metrics.
Those won't hold any statistical validity because they're not actually
random samples.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/

On 11/27/21 12:16 PM, William Herrin wrote:
> On Fri, Nov 26, 2021 at 3:07 PM Michael Thomas <mike@mtcc.com> wrote:
>>> On 11/26/21 1:44 PM, Jean St-Laurent via NANOG wrote:
>>> Here are some maths and 1 argument kicking ass pitch for CFO’s that use iphones.
>>> Apple tells app devs to use IPv6 as it's 1.4 times faster than IPv4
>> This really hits my bs meter big time.
> If I had to guess, this is an example of correlation is not causation.
> Folks with IPv6 tend to be on savvier service providers who have
> better performance for both IPv4 and IPv6. To find out for sure,
> you'd have to do an experiment where same-user-same-server connections
> are split between IPv4 and IPv6 and then measure the performance
> difference. I don't know if anyone has done that but these particular
> articles look like someone is just looking at the high-level metrics.
> Those won't hold any statistical validity because they're not actually
> random samples.

I agree. It's pretty suspect that they didn't give the reason it was
happening. I mean, why the incuriosity?

Mike

On 26/11/2021 22:47, Jean St-Laurent via NANOG wrote:
> "And when IPv6 is in use, the median connection setup is 1.4 times
> faster than IPv4. This is primarily due to reduced NAT usage and
> improved routing."

Oh I believe IPv6 is faster but because of completely different reasons.
Modern faster connections more likely have IPv6 while old low-bandwidth
circuits may provide v4 only.

Some users may also use VPN which is almost always v4 only. Their VPN
may do funny routing, hair-pinning and similar behavior thus impacting
their performance.

--
Grzegorz Janoszka

Actually, I think it’s in the fine print here…

“Connection setup is 1.4 times faster”. I can believe that NAT adds almost 40% overhead to the connection setup (3-way handshake) and some
of the differences in packet handling in the fast path between v4 and v6 could contribute the small remaining difference.

I doubt it is due to different connections, since we’re talking about measurements against dual-stack sites reached from dual-stack end-users,
very likely traversing similar paths.

Owen


> On Nov 27, 2021, at 14:02 , Grzegorz Janoszka <grzegorz@janoszka.pl> wrote:
>
> On 26/11/2021 22:47, Jean St-Laurent via NANOG wrote:
>> "And when IPv6 is in use, the median connection setup is 1.4 times faster than IPv4. This is primarily due to reduced NAT usage and improved routing."
>
> Oh I believe IPv6 is faster but because of completely different reasons.
> Modern faster connections more likely have IPv6 while old low-bandwidth circuits may provide v4 only.
>
> Some users may also use VPN which is almost always v4 only. Their VPN may do funny routing, hair-pinning and similar behavior thus impacting their performance.
>
> --
> Grzegorz Janoszka

On 11/27/21 2:22 PM, Owen DeLong via NANOG wrote:
> Actually, I think it’s in the fine print here…
>
> “Connection setup is 1.4 times faster”. I can believe that NAT adds almost 40% overhead to the connection setup (3-way handshake) and some
> of the differences in packet handling in the fast path between v4 and v6 could contribute the small remaining difference.
>
> I doubt it is due to different connections, since we’re talking about measurements against dual-stack sites reached from dual-stack end-users,
> very likely traversing similar paths.
>
40% in isolation is pretty meaningless. If it's 40% of .1% overall it's
called a rounding error.

Mike

Well, 1.4x faster is a bit of an odd metric. I presume that means that connection set up times measured were on average
1/1.4 times as long for IPv6 as they were for IPv4, but there are other possible interpretations.

So really, that’s a convoluted way of saying it takes 29% less time to set up an IPv6 connection than an IPv4 connection on average.

I can believe that is likely in a scenario where one is dealing with IPv4 NAT overhead.

It’s still probably rounding error for any real world purpose, since we’re probably talking about something that normally takes
between 50 and 150 ms, so if it takes 1.4 times as long in IPv4, that’d be 70-210 ms, so still mostly under 1/5th of a second,
which is not below human perception, but likely below human notice.

Owen


> On Nov 27, 2021, at 14:30 , Michael Thomas <mike@mtcc.com> wrote:
>
>
> On 11/27/21 2:22 PM, Owen DeLong via NANOG wrote:
>> Actually, I think it’s in the fine print here…
>>
>> “Connection setup is 1.4 times faster”. I can believe that NAT adds almost 40% overhead to the connection setup (3-way handshake) and some
>> of the differences in packet handling in the fast path between v4 and v6 could contribute the small remaining difference.
>>
>> I doubt it is due to different connections, since we’re talking about measurements against dual-stack sites reached from dual-stack end-users,
>> very likely traversing similar paths.
>>
> 40% in isolation is pretty meaningless. If it's 40% of .1% overall it's called a rounding error.
>
> Mike

On Sat, Nov 27, 2021, 17:36 Owen DeLong via NANOG <nanog@nanog.org> wrote:

> Well, 1.4x faster is a bit of an odd metric. I presume that means that
> connection set up times measured were on average
> 1/1.4 times as long for IPv6 as they were for IPv4, but there are other
> possible interpretations.
>
> So really, that’s a convoluted way of saying it takes 29% less time to set
> up an IPv6 connection than an IPv4 connection on average.
>
> I can believe that is likely in a scenario where one is dealing with IPv4
> NAT overhead.
>


Why isn't this just inconsistent paths between V6 and V4/nat? (Divergent
topologies)

> On Nov 27, 2021, at 17:21 , Christopher Morrow <morrowc.lists@gmail.com> wrote:
>
>
>
> On Sat, Nov 27, 2021, 17:36 Owen DeLong via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote:
> Well, 1.4x faster is a bit of an odd metric. I presume that means that connection set up times measured were on average
> 1/1.4 times as long for IPv6 as they were for IPv4, but there are other possible interpretations.
>
> So really, that’s a convoluted way of saying it takes 29% less time to set up an IPv6 connection than an IPv4 connection on average.
>
> I can believe that is likely in a scenario where one is dealing with IPv4 NAT overhead.
>
>
> Why isn't this just inconsistent paths between V6 and V4/nat? (Divergent topologies)

At least in most of my real world experience, they don’t tend to diverge all that much.

Further, post-initiation performance seems to be largely on par v4<->v6 and without NAT, I see faster
v4 connection startup times. V6 appears to still have a slight advantage, but it’s more like 5-10% than
30%.

Owen

Mark Tinka wrote:

> On 11/27/21 17:07, Masataka Ohta wrote:
>
>> Because lengthy IPv6 addresses mean a lot more opex than IPv4.
>
> I disagree

Try to type in raw IPv6 addresses.

Masataka Ohta

On Nov 27, 2021, at 7:39 PM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> ?Mark Tinka wrote:
>
>>> On 11/27/21 17:07, Masataka Ohta wrote:
>>> Because lengthy IPv6 addresses mean a lot more opex than IPv4.
>> I disagree
>
> Try to type in raw IPv6 addresses.

People are likely to use a technology originally developed because IPv4 had the same perception problem: DNS.