Last month we covered the 2015 leap second ahead of the insertion of a leap second at the very end of 2016. As stated previously, leap seconds can trigger poorly-tested code paths; leap second handling always unearths bugs and issues. This one was no exception!
On 31 December this year, we’re scheduled for another leap second. There are many stories about what leap seconds can do to infrastructure and applications, and rituals are built up around them. Such rituals stem from reality: leap seconds trigger poorly-tested code paths and run contrary to assumptions that system time always runs in one direction. It’s useful to be aware of how your infrastructure handles leap seconds and how NTP servers handle them, so you can plan around the event. Here, we look at some of the NTP measurements the RIPE Atlas platform took around the last leap second, and approaches for handling them.
Today marks my last day at Yahoo, almost three years since I started. It’s been a fun ride!
The job took three hats:
It was a great trade-off, and watching IPv6 deployment grow in one of the largest content networks in the world (the 5th largest in September 2016) was a lot of fun.
Of course, the measurement work was important because a lot of the interesting stuff was happening elsewhere. Measuring deployment of IPv6, as observed on Yahoo’s CDN services, was critical.
Three years ago, 3.4% of our traffic was carried over IPv6. Today, our global metrics show that we’re regularly handling 15% of requests over IPv6 at weekends. So we’re talking about an almost five-fold increase in traffic in consumer-facing ISPs, and an equivalent reduction in IPv4.
Back then, there were far fewer ISPs carrying significant IPv6 traffic. Verizon Wireless, Comcast, Deutsche, Free, and Swisscom all had significant deployments (over a third of their traffic was IPv6 at the time), and other networks such as T-Mobile (US) (hovering around 7% IPv6) were picking up. This is the post-IPv6-Launch event world, where ISPs were getting comfortable with IPv6 for all customers.
We’ve seen so many ISPs ramp up their IPv6 deployments since then. Comcast is now consistently 50% IPv6, approaching 60% at the weekends (work-week hours drive IPv4 traffic in many fixed-line networks, something we identified in the ANRW paper). Some networks are pushing harder: T-Mobile (US) is hitting the 80% mark, as is Verizon Wireless. These networks in particular help boost our recent assertion that mobile traffic in the US is now majority IPv6. Another big jump was Sky Broadband in the UK, who successfully ramped up their IPv6 deployment to level out around 78% IPv6. In a domestic, fixed-line ISP, that’s strong work, and it’s a huge reduction in our IPv4 load.
Many ISPs operate within a given jurisdiction or market, and therefore countries are a natural way to aggregate the traffic stats. We have so many countries with traffic today that had almost none in 2013.
At the country level, in 2013 traffic originating from ASNs registered in the US was close to 7% IPv6; Germany was around 8%, Romania was around 11%, and Switzerland was around 16%, but many were near-zero. So small compared to today. Now, the US is consistently around 30% IPv6 to Yahoo. Sky’s light-up brings the UK to around 15% IPv6. Belgium these days is over 40% IPv6, and Germany’s a comfortable 20%.
Building out a list of countries where we see more than 5% of traffic carried over IPv6, here’s what we see, now and then:
For the sake of clarity, country stats are derived by taking the origin ASN for each request and mapping it to the country code the origin ASN is registered to (according to data published by the registries: AfriNIC, APNIC, ARIN, LACNIC, RIPE NCC); this is a rough but simple measure of where traffic is coming from.
Obviously, countries vary wildly by population, and India’s recent uptick in IPv6 traffic is more significant – in terms of traffic, and where you handle it – than most of the European countries listed, but most of these are strong showings. IPv6 is on the way up.
The key points from some of our measurement are basically:
In other spaces, key moves are encouraging. Apple’s IPv6 requirements for app developers, and Amazon’s announcement of IPv6 for S3 are big moves forward, reducing the number of IPv4-only services that engineers are exposed to, or writing code for.
But from my perspective inside Yahoo, that’s that. In December, I start a new gig, measuring the network from different perspectives. Including, of course, the IPv6 perspective!