Given YouTube/Google’s preference to connect users via IPv6, researchers in Europe recently presented the results of a three-year study that sought to measure the difference between YouTube content delivery over IPv6 and over IPv4 to understand which one provides the better user experience.
Using a 34-month-long dataset (Aug 2014 to Jun 2017), researchers from TU Munich, Jacobs University Bremen, and Aalto University showed that the success rates of streaming a stall-free version of a YouTube video over IPv6 have improved over time — a Happy Eyeballs (HE) race during initial TCP connection establishment leads to a strong (more than 97%) preference over IPv6.
Read the full paper and watch lead author Vaibhav Bajpai’s presentation from IETF 99 below.
However, this preference to stream over IPv6 does not translate to improved performance. Over the course of the study, the researchers observed:
- Higher TCP connection establishment times and startup delays (∼100 ms or more) over IPv6.
- Lower achieved throughput both for audio and video streams over IPv6, although the difference in throughput has improved over time.
- Less than 1% stall rates over IPv4 and IPv6. However, in situations where a stall does occur, 80% of the samples experience stall durations that are at least one second longer over IPv6, a figure that has not reduced over time.
- The worse performance over IPv6 is due to the disparity in the availability of Google Global Caches (GGC) over IPv6. Around 97% of the probes received content delivery through a content cache over IPv4 while only 5% received it from a content cache over IPv6.
So why is YouTube preferring IPv6 even though it provides worse performance?
According to the paper, this is because “browsers use a HE timer value that has passed its time. The HE timer value (300 ms) was chosen during a time (2012) when broken IPv6 connectivity — attributed largely to failures caused by Teredo and 6to4 relays — was quite prevalent.”
However, within a span of five years, Teredo/6to4 presence has declined to ∼0.01% as of June 2017. In this changed landscape, the researchers measured the effects of HE and observed that an HE timer value of 150 ms provides a margin benefit of ∼10% while retaining the same preference levels over IPv6.
As a result of these findings, the research team recommend that web browsers need to reduce the HE timer value to 150 ms to help reduce the performance penalty in situations where IPv6 is considerably slower.
The team also recommend that ISPs need to prioritize latency when optimizing their broadband networks, and ensure that their GGC nodes are dual-stacked.
The v6ops working group within the IETF is undergoing rechartering, where one of the goals is to update the HE standard with operational experience, something this research will help to inform and improve.
To help with reproducibility, the entire dataset and software used in this study has been made available to the measurement community and is available to download from GitHub.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Actually Happy Eyeballs is being updated in v6ops.
The WG has already done the last call, so it will be a new RFC in a matter of weeks (I guess).
The document is here:
Obnoxious premise and title for an article, comparing performance. IPv6 performance is fine. We all need the address space of IPv6 and should be using IPv6 going forward, period. Better questions would be:
– why is it taking so long for enterprise networks to roll out IPv6?
– why are some major content providers dragging their heels on IPv6?
– why is Verizon FIOS totally AWOL on IPv6? Verizon Wireless is doing great with IPv6, so it’s puzzling that Verizon VIOS has zero IPv6 capabilities.
in Tonga ipv6 is faster for content host far away from us …even though latency to that destination is better for v4 than v6
ipv6 is faster for us in Tonga … ive done detail test and find content pull from source far away from us …