Why IPv6 Matters: Mobile Performance

The last week, in my spare time, I saw very interesting talks about how to improve Mobile App Performance.

One particular topic who came in many conversations with my team was the Internet Protocol version 6, well known as IPv6, the next generation Internet Protocol, who solves not just the problem of IPv4 exhaustion, but it’s thought to other problems like security and true end-to-end connectivity.

So, I began to dig even deeper why IPv6 matters today for Mobile Performance, and fortunately, I found a lot of cases, people and teams working in the same problem.

Like always, YouTube is an oustanding resource when you are looking for technical expertise for certain topic; and looking at the site, I found two very interesting talks about IPv6.

The first talk was a panel session in the NANOG 64 Conference called: “The benefits of deploying IPv6 only” with Geoff Huston (APNIC), Gaurav Madan (T-Mobile USA Inc.), John Jason Brzozowski (Comcast Cable (they announced that their IPv6 deployment is completed)), and Paul Saab (Facebook). In this panel, moderated by Geoff; all of them discussed the state of IPv6 on their respective companies, the benefits (and challenges) behind it, and why it matters for the future of Internet

I encourage to watch the entire session, it’s totally worth it.

The second session was “IPv6 is Here and You are hurting your Users”, in the past @Scale 2015 conference with Paul (again) explaining why IPv6 matters for Mobile performance, explaining in the case of Facebook with facts and numbers how IPv6 is helping them to achieve a 40% faster on it. What?

Paul said to understand this, he sat down with the Data Science team at Facebook, and they concluded that the exact number was 15% faster in IPv6

You probably are wondering if a 15 percent increase matters; guest what, it matters; like Paul said: “It’s a huge performance gain”. And when you see the major carriers in United States (and other parts of the world) investing heavily on IPv6, yes my friends, this matters more than ever.

The last numbers behind this are very encouraging, and in the past WWDC Conference by Apple (I will talk more about this later), they showed this graphic:

A particular case I will highlight here is Verizon Wireless, because united to this graphic, showing that they are in the top of IPv6 deployment in U.S, they made a key partnership with Cisco to be the first U.S Mobile carrier to deploy 5G network technology in U.S (If you want to dig on 5G, I encourage to read a paper from Chetan Sharma about this: 5G — The Past, Present, and Future of the Mobile Industry Evolution), and if you think this is a coincidence, you are wrong.

This come with the other major partnership between Apple and Cisco, so everything is connected my friend, and like Paul said:

“If you are not thinking in IPv6 today, you will be stuck”

Now, in the last minutes of Paul’s session @Scale (11:30), he invited to John (Comcast Cable, again), Axel Clauberg (VP Aggregation, Transport IP at Deutsche Telekom), Samir Vaidya (Director of Device Technology, Verizon Wireless) and Mingeun Yoon (Projet Manger Emerging Tech at SK Telecom) because you need to know that carriers are in the IPv6 race around the world; and he asked some questions to highlight why IPv6 matters:

Why IPv6 matters for Mobile Performance?

OK, in this point, you captured the point that I want to emphasize, and you should be wondering why IPv6 could improve the performance of your Mobile application if you use IPv6-only networks. We are not ready for an IPv6-only Mobile-backend, so many people is working on this case with dual stacks.

Then, I began to search more about performance evaluation of IPv4 and IPv6 networks, and what I found it’s very encouraging.

For example, I found an incredible article from Emile Aben, in the RIPE Labs site called “Measuring World IPv6 Launch — Comparing IPv4 and IPv6 Performance”, where he described their finding with these sentences:

Comparable IPv4 and IPv6 performance can be seen as an indication of a mature deployment of both IPv4 and IPv6 in a network. In the data we analyzed we see IPv4 is still generally faster then IPv6, but for a significant fraction of measurements IPv6 is the faster protocol.

This year we saw in roughly 10% of the cases that IPv6 was already faster, and with further maturation of the IPv6 network this is only expected to rise. When there is a difference in performance it is typically IPv4 that is faster. When there is a major difference in performance we see this typically being caused by IPv4 and IPv6 end-points for a single hostname being terminated at physically different locations.

There is some potential benefit from this information for applications that need their communications to be as real-time as possible, like Internet telephony/video or gaming. For end-hosts that are dual-stacked, there are now two chances (IPv4 and IPv6) for the fastest method to get packets to another dual-stacked end-host, not only IPv4 anymore.
So being dual-stacked means 2 chances for best performance!

Major carriers are in the fast race for full IPv6-only networks deployment

The last numbers behind of IPv6 deployment for major carriers around the world are very interesting.

North America

AT&T: 50.06%
Verizon Wireless: 72.23%.
T-Mobile: 48.86%. Note: T-Mobile US default settings for all Android and Windows phone to be IPv6 only/464XLAT (I will talk about this later)
Sprint: 45%
TELUS (Canada): 2.85%. Read the news here

South America

GVT (Brazil): 11.48%. Read the recent news in the World IPv6 Launch
Telefonica del Peru: 19.21%

Europe, Middle East and Africa

British Telecom (UK): 0.03%, but Their plans are very aggressive, and they have a site dediccated to IPv6
Deutsche Telekom (Germany): 22.59%
Swisscom (Switzerland): 41.49%
Utility Line Italia srl (Italy): 4.09%
Orange Poland: 4.04%
British Sky Broadcasting: 9.86%

Asia

SK Telecom: 23.92%
China Telecom: 0.23%
Telekom Malaysia: 16.33%. This is one of the Top 10 IPv6 Networks.
VentraIP Group (Australia) Pty Ltd: 41.23%
Softbank (Japan): 4.66%
KDDI (Japan): 22.29%
NTT (Japan): 1.39%

Now, every carrier Mobile network has its own network constraints, and one important variable here is: network latency.

If you saw the talk from Ilya Grigorik (Google) called Startup Lab Workshop Mobile Performance, you should have seen this picture:

where he explained how Radio Access Networks works, and how they delivers the content for a Mobile user. Then, he explained the (short) life of a web request:

where he explained how many roundtrips are done, even before to send you any data to your phone, and I want to stop here:

The number of full roundtrips made by your Mobile app matters

, and Ilya said the average size of assets in a web page today is 90. Think in Javascript files, CSS files, images files as assets. So, if you have more assets in your Mobile app, the roundtrips number will be higher right?

But why IPv6 could help you here? Mainly because IPv6 packet size is larger, so when you make a request to an IPv6-capable server, it can send you more data in a single HTTP request, so it could translate it to a less roundtrip number, so the content of your Mobile app will be loaded even faster.

In a 4G network, every RoundTrip Time (RTT) is from 100 ms, and in a 3G network, the RTT is from 200 ms. Now, in the case of LTE, the RTT is from 40–50 ms, which is great for Mobile users, but remember: the number of your assets matters, so you have to take a deep look on this.

But how is IPv6 packet size larger than IPv4 packet size? Well, reading the book of Joseph Davies called “Understanding IPv6”, you can understand this. In the Chapter 4 of the book called “The IPv6 Header”, Joseph explained this brilliantly, describing everything about IPv6 and making its comparisson with IPv4:

In the case of an IPv6 packet, it consists of an IPv6 header (RFC 2460), extension headers, and an upper layer protocol data unitThe IPv6 packet payload is the combination of the IPv6 extension headers and the upper-layer PDU. Normally, it can be up to 65,535 bytes long. IPv6 packets with payloads larger than 65,535 bytes in length, known as jumbograms, can also be sent.

You need to remember that the size of IPv6 adddresses are of 128-bits, so they are larger than IPv4 addresses.

Following with Ilya’s talk, he explained the importance of TCP Congestion Control algorithm, and how to avoid it with an Ingestion Window changed from 4 to 10 in the kernel of your server. After that, he made the example of a 40KB request, counting the number of roundtrips involved and the Total Time to Render the page:

Now, what would happen if you send more data in a single roundtrip to your Mobile user? Instead to send ~ 14 KB in the first RTT, you could send 20 KB or 25 KB in that first RTT?

You could reduce the total number of roundtrips made to the server, which could be translated to a faster user experience in your Mobile app. Now, think in this particular test, formuling some key questions here:

How this works for me in an IPv4-based Mobile backend?
How this works for me in an IPv6-based Mobile backend?
What happens in a dual-stack Mobile backend?
What happens in an IPv6-only Mobile backend?

You need to ask and answer these questions right now, because if you don’t do it quickly, you probably lose a lot of users with IPv6 full capacity, because they are being redirected to a IPv4-gateway, increasing the network latency for a single request. But the story doesn’t end here. What about the major Mobile OS? What about Apple’s iOS and Google’s Android?

Apple’s iOS 9 and IPv6-capable obligated requirement for apps has changed the Mobile landscape (again)

In the last September, in the past WWDC by Apple, they made the official announcement of iOS 9 and watchOS 2, the new version of its Mobile Operating Systems, but one particular thing came to light in the Session 719 given by Prabhakar Lakhera and Stuart Cheshire called “Your App and Next Generation Networks”:

Did you remember my post about the partnership between Apple and Cisco?

This is other of the reasons why this partnership is critical for the Enterprise world; because IPv6 gives a better capability for packet prioritization, the technical thing behind the “Fast Lane” phrase I think, in the official announcement by the two companies.

Cisco’s equipment has full support for IPv6, so if they are working with Apple to improve Networking capabilities of iOS 9’s software, this is the right way to do it.

But this is not the only thing that Apple did with iOS 9.

They incorporated to the OS ad-blocking capabilities and a revamped Spotlight search; a direct strike to Google’s main revenue sources. But, you should be wondering why this matters for the article.

I will use two sentences of the the article of Emma Crowe (Chief of Client Strategy at Somo) at VentureBeat about this topic:

Ultimately, this puts people in a place where they can essentially create a curated web on their device. Just by downloading the apps and services they want it creates a selective pre-built ‘pool’ of content to search within.

This is already a tectonic shift which begins to set sail from the Google anchor.Apple has very cleverly considered the personalized nature of mobile to create a store of results that sits locally on a user’s device. This keeps personal data safer and ensures search relevancy as it’s hyper-personalized and in the eyes of the user, higher quality.

The company has also combined this local index with a public cloud index that stores publically available results. Crucially, the cloud index also provides methods to submit app content so the users can also be served an in-app result without having that specific app on their device. The result is that when users search, they’ll see results for the apps on their device AND the apps not on their device. This will keep even more people on the iOS ecosystem, and crucially, away from Google.

Are you wondering which is the platform for innovation here? I will speculate in this point: Yes, with other things involved in the Search platform (Did you know they use Apache Solr and Apache Mesos? See the talk called SolrCloud at Apple: Automating and scaling for Massive Multi-Tenancy from Jessica Mallet at the past Lucene Revolution,

IPv6 is the perfect fit for this, because in that way, Apple could maintain a better synchronization between the local index in the Mobile phone, and the public cloud, because if they could use your own IPv6 address provided by your carrier, they could give you a great User Experience.

So, if you are an iOS/watchOS developer and you are not working on this, perhaps your Mobile app will not be in the next year in the App Store, so you need to work on this right now. Fortunately, Prabhakar and Stuart gave great suggestions in their talk how to tackle this problem, but for this, you need to have your Mobile-backend IPv6-capable too, this is not a trivial change, this needs to be carefully planned for everyone involved on this.

So, again: if you are an iOS/OSX developer, you must see the talk, particularly the Stuart’s part, where he talked about the benefits of using NSURLSession and CFNetwork-layer APIs, Reliable Network Fallback, Explicit Congestion Notification, TCP_NOTSENT_LOWAIT and TCP Fast Open technology.

Now, what about Android 5/6?

Seeing the NANO 64’s talk, I saw Gaurav Madan, talking about NAT64/DNS64, which brought some problems to T-Mobile US with Mobile apps like WhatsApp, Spotify and Skype, that didn’t work with IPv6-only clients.

Then, T-Mobile, in partnership with NEC and JPIX (with contributions from Google too), documented 464XLAT in the IETF as RFC 6877 to overcome the limitations of NAT64 by adding a NAT46 into the client (CLAT). iOS has support for 464XLAT, Windows Phone 8.1 too, and in the case of Android, they was introduced in October, 2013. To see a quick explanation of 464XLAT, you can see this quick video from APNIC:

To evaluate the support of IPv6 in Android, you can see all APIs in the SDK, from API level 14 (Android 4.0 Ice Cream Sandwich), which has support for IPv6 (except for DHCPv6), with a lot of APIs ready to use, Networking-related notifications and more things.

I don’t know if Google will introduce a requirement like Apple did, but for example, if you want to grow your Monthly Active Users, you need to work on this quickly.

I was searching for best practices how to make your Android app IPv6-complaint, and I found these incredible resources:

Does Android have support for IPv6?
IPv6 and More
How can I connect to an IPv6 address on Android?
FourSixFourXlat
IPv6Droid
Developing IPv6-enabled Apps with FIWARE
Android CLAT
IPv6 in Android Open Source code

In the last versions of Android (Lollipop and Marshmallow), the development team improved the Networking APIs with more capabilities, and like Google is one of the first companies to support IPv6, they has tested everything to work with this standard.

Even, I think that IBM SoftLayer could increase its offering in the upcoming years like the preferred partner to create Mobile-backend platforms, because Amazon Web Services is promising for the last 3 years, they “eventually” will provide full support for IPv6-capable services, but until this date, only two of the services has partial IPv6 capabilities: Elastic Load Balancing and Amazon Route 53. If you want to know more about this, read these links:

and if you are looking other Cloud platforms who has full support for IPv6, you can use:

Now, to work on Android apps to fully support IPv6 and IPv4, because like I said before, we are not ready yet to use IPv6-only; you need to be aware of one thing. If your Mobile-backend server has the two records for DNS: an A record for IPv4, and an AAAA (or quad A) for IPv6, Which address will your Mobile app default to using when contacting the host?

This is one of the key questions you can find in the Dan York’s “Migrating Applications to IPv6” minibook: There is one solution to this problem: “Happy Eyeballs” (HE). HE’s principles are very simple, and I will use the words of Dan here:

A potential solution to the prioritization issue is a proposal within the IETF referred to as the “happy eyeballs” solution. On the face of it, “happy eyeballs” is an extremely simple idea: When you receive both an A and an AAAA record, try contacting the site using both addresses and then use whichever address responds first.If the IPv6 address is available and able to respond quickly, the communication will happen over IPv6. If an IPv6 connection isn’t available, the communication will occur over IPv4. Similarly, if the IPv6 connection is slower, perhaps because it is tunneled over IPv4, the application uses the faster IPv4 connection.

Facebook has its own implementation of Happy Eyeballs for Android, but they have not released yet, because they think it’s not ready for public yet. But, you must follow the work at GitHub.

And if you want to see more good use of Happy Eyeballs deployment, you can read this article from Emile at RIPE Labs about two different use-cases (The IETF RFC for Happy Eyeballs is RFC 6555) .

What about Mobile-backend platforms?

Many applications developers are using Nodejs, as part of the MEAN Stack for Mobile-backend platforms; and guest what: Nodejs has support for IPv6.

A quick trick that you could use, it’s the given tip by York in his minibook:

var http = require(‘http’);
var handler = function (request, response) { response.writeHead(200, {“Content-Type”:”text/plain”});
response.end (“Hello World!\n”);
console.log(“Got a connection from “ + request.connection().stream.remoteAddress); };
var server= http.createServer(); server.addListener(“request”,handler); server.listen(80,”198.51.100.22");
var server6= http.createServer(); server6.addListener(“request”,handler);
server6.listen(80,”2001:db8:42d7::2"); console.log(“Server running on localhost at port 80”);

If you use MongoDB for your DB backend, it has support for IPv6 too, and if you are using PostgreSQL, it has support for IPv6 from a long time ago. The list is growing everyday:

Nginx 1.9.5. Here, you can see an example. (BTW, if you want commercial support for your Nginx, you need to see this post from Owen Garret about Nginx Plus R7, where both products has full support for HTTP/2)
Unicorn in the Rails world
Docker for Containers-based Mobile-backend apps
Redis has support for IPv6 too

, and many more. So, it could be done with the same tools you are using for your Mobile-backend platform.

Conclusions

So, again: you need to sit down with your Mobile Development team, and think how to make the transition to IPv6 for your Mobile apps, how to maintain a dual-stack for the moment, and you must create an environment focused to test an IPv6-only Mobile backend solution.

This is the future, folks, and believe it’s not very far, it’s almost here. And when you did this, you will be helping to get on board more users, because you will improve the performance of your Mobile app; and there is a simple formula to understand why you need to think on this right now:

A best Mobile Performance, means more happy users with your app, which is equal to more traffic for your app and more revenue in the long term.

If you are looking for companies in the same page, you must use the World IPv6’s site for it. They list every company in the world with IPv6-capable networks, so it’s the place to see the steady growth of IPv6’s adoption around the world and if you are looking for IPv6 experts and iOS/Android developers with experience on this, you can ask to:

IPv6 Experts