Hi, Eduard:

0) Thanks for sharing your research efforts.

1) Similar as your own experience, we also recognized the granularity issue of the data in this particular type of statistics. Any data that is based on a limited number of countries, regions, businesses, industry segments, etc. will always be rebutted with a counter example of some sort. So, we put more trust into those general service cases with continuous reports for consistency, such as AMS-IX. If you know any better sources, I would like to look into them.

Regards,


Abe (2022-11-24 11:59 EST)


On 2022-11-24 04:43, Vasilenko Eduard wrote:
Hi Abraham,
Let me clarify a little bit on statistics - I did an investigation last year.

Google and APNIC report very similar numbers. APNIC permits drilling down deep 
details. Then it is possible to understand that they see only 100M Chinese. 
China itself reports 0.5B IPv6 users. APNIC gives Internet population by 
country - it permits to construct proportion.
Hence, it is possible to conclude that we need to add 8% to Google (or APNIC) 
to get 48% of IPv6 preferred users worldwide. We would likely cross 50% this 
year.

I spent a decent time finding traffic statics. I have found one DPI vendor who 
has it. Unfortunately, they sell it for money.
ARCEP has got it for France and published it in their "Barometer". Almost 70% 
of application requests are possible to serve from IPv6.
Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 worldwide 
because France is typical.
My boss told me "No-No" for this logic. His example is China where we had 
reliable data for only 20% of application requests served on IPv6 (China has a very low 
IPv6 adoption by OTTs).
My response was: But India has a much better IPv6 adoption on the web server 
side. China and a few other countries are not representative. The majority are 
like France.
Unfortunately, we do not have per-country IPv6 adoption on the web server side.
OK. We could estimate 60% of the application readiness as a minimum. Then 
60%*48%=28.8%.
Hence, we could claim that at least 1/4 of the worldwide traffic is IPv6.

IX data shows much low IPv6 adoption because the biggest OTTs have many caches 
installed directly on Carriers' sites.

Sorry for not the exact science. But it is all that I have. It is better than 
nothing.

PS: 60% of requests served by web servers does not mean "60% of servers". For 
servers themselves we have statistics - it is just 20%+. But it is for the biggest web 
resources.

Eduard
-----Original Message-----
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei....@nanog.org] On 
Behalf Of Abraham Y. Chen
Sent: Thursday, November 24, 2022 11:53 AM
To: Joe Maimon<jmai...@jmaimon.com>
Cc: NANOG<nanog@nanog.org>;b...@theworld.com
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Dear Joe:

0) Allow me to share my understanding of the two topics that you brought up.

1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone 
from ~0% to ~40% in 12 years.... ":  Your numbers may be deceiving.

    A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified 
on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your 
impression. That is, the IPv6 has been around over quarter of a century.

    B. If you read closely, the statement  "The graph shows the percentage of users that 
access Google over IPv6." above the graph actually means "equipment readiness". That 
is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose 
title makes this clearer. However, having the capability does not mean the owners are actually 
using it. Also, this is not general data, but within the Google environment. Since Google is one of 
the stronger promoters of the IPv6, this graph would be at best the cap of such data.

    C. The more meaningful data would be the global IPv6 traffic statistics. 
Interestingly, they do not exist upon our extensive search.
(If you know of any, I would appreciate to receive a lead to such.) The closest 
that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). 
It is currently at about 5-6% and has been tapering off to a growth of less 
than 0.1% per month recently, after a ramp-up period in the past. (Similar 
saturation behavior can also be found in the above Google graph.)

https://stats.ams-ix.net/sflow/ether_type.html

    D.  One interesting parameter behind the last one is that as an 
Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix 
between IPv6 and IPv4. The low numbers from AMS-IX does not support this 
viewpoint for matching with your observation. In addition, traffic through IX 
is the overflow among backbone routers. A couple years ago, there was a report 
that peering arrangements among backbone routers for IPv6 were much less 
matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic 
than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall 
Internet traffic should be less than what AMS-IX handles.

    E. This is a quite convoluted topic that we only scratched the surface. 
They should not occupy the attention of colleagues on this list. However, I am 
willing to provide more information to you off-line, if you care for further 
discussion.

2)  "...https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/
...":  My basic training was in communication equipment hardware design.
I knew little about software beyond what I needed for my primary assignment. 
Your example, however, reminds me of a programing course that I took utilizing 
APL (A Programming Language) for circuit analysis, optimization and synthesis. 
It was such a cryptic symbolic language that classmates (mostly majored in EE 
hardware) were murmuring to express their displeasure. One day we got a 
homework assignment to do something relatively simple. Everyone struggled to 
write the code to do the job.
Although most of us did get working codes, they were pages long. The shortest 
one was one full page. Upon reviewed all homework, the professor smiled at us 
and told us to look for the solution section at the end of the text book. It 
turned out to be the answer for a problem in the next chapter to be covered. 
The code was only three lines long!
Although it did not have the codes for debugging purposes, it covered all error 
messages expected. It was such a shocker that everyone quieted down to focus on 
the subject for the rest of the semester. During my first employment, we had 
the need to optimize circuit designs. Since I was the only staff who knew about 
it, I ended up being the coordinator between several hardware designers and the 
supporting programmer. From that teaching, I am always looking for the most 
concise solution to an issue, not being distracted or discouraged by the 
manifestation on the surface.

https://en.wikipedia.org/wiki/APL_(programming_language)

3) Fast forward half a century, I am hoping that my "one-line code"
serves the purpose of "there exists" an example in proofing a mathematical 
theorem for  inspiring software colleagues to review the network codes in front of them 
for improvement, instead of presenting such as a valid hurdle to progress.


Regards,


Abe (2022-11-24 03:53 EST)





On 2022-11-21 19:30, Joe Maimon wrote:
David Conrad wrote:
Barry,

On Nov 21, 2022, at 3:01 PM,b...@theworld.com  wrote:
We've been trying to get people to adopt IPv6 widely for 30 years
with very limited success
According tohttps://www.google.com/intl/en/ipv6/statistics.html, it
looks like we’ve gone from ~0% to ~40% in 12 years.
https://stats.labs.apnic.net/ipv6  has it around 30%. Given an
Internet population of about 5B, this can (simplistically and
wrongly) argued to mean 1.5-2B people are using IPv6. For a
transition to a technology that the vast majority of people who pay
the bills will neither notice nor care about, and for which the
business case typically needs projection way past the normal
quarterly focus of shareholders, that seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4
Titanic, the fundamental and obvious flaw is the assertion of
"commenting out one line code”. There isn’t “one line of code”. There
are literally _billions_ of instances of “one line of code”, the vast
majority of which need to be changed/deployed/tested with absolutely
no business case to do so that isn’t better met with deploying
IPv6+IPv4aaS. I believe this has been pointed out numerous times, but
it falls on deaf ears, so the discussion gets a bit tedious.

Regards,
-drc

Had the titanic stayed afloat some hours more, many more would have
survived and been rescued when assistance eventually arrived. So that
makes this a debate over whether this is deck chair re-arrangement or
something more meaningful.

As I and others have pointed out, it depends on how it is used. And
perhaps the attempt should be made regardless of knowing in advance
which it will be.

You assertion needs some back of the envelope numbers, which once
provided, I suspect will render your estimate grossly incorrect.

You can hardly attempt to convince anybody that 240/4 as unicast would
not be the more trivial change made in any of these products natural
life cycle points.

Especially as we have examples of what that type of effort might look
like. IGTFY and here

https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/

The burdensome position is ridiculous even more so when stated with a
straight face.

Joe



--
This email has been checked for viruses by Avast antivirus software.
www.avast.com



--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Reply via email to