A couple of weeks ago, I posted an article about slow IPv6 DNS query performance. Several readers suggested in the comments that my observations were isolated to a few bad implementations and that perhaps Mac and Linux systems were not prone to this. I hoped they were right, but I now have data to show they’re wrong.
Measuring performance is routine in Chrome, so a couple of days ago I was able to add a simple test to measure the speed of pure IPv4 lookups (A record) vs IPv6 lookups (A + AAAA records). Today, with hundreds of millions of measurements in hand, we know the impact of IPv6 on DNS.
Windows users face a ~43% DNS latency increase and Mac users face a 146% DNS latency increase when they install an IPv6 client-side address on their machines.
Today, there are two basic approaches to the IPv6 lookup problem: you can issues the requests in serial or in parallel. Obviously, issuing in serial will be more latency impacting than doing them in parallel. But, even issuing them in parallel will be slower, as the maximum latency of two samples along a normal curve will be lower than the average latency of a single sample along the same curve.
Some readers may argue that these are dominated by older implementations. Further investigation into the data does not confirm this. Even comparing the fastest 10% of Mac or Windows users (which should hopefully be using the best DNS resolver algorithms available) are seeing greater than 100% DNS lookup latency increases with IPv6. Of course, we have conflation here, as DNS server response times may be slower in addition to the DNS client double-lookup being slower. A deeper study about why these results are so bad is warranted.
Summary
Performance-sensitive users should be cautious about assigning a global IPv6 address on their clients. As soon as they do, the browser will switch into IPv6 lookup mode, and take on a 40-100% increase in DNS latency.
Surely you mean that if you take the greater of two samples from the same curve, then on average it will be higher than the a single sample? I.e., if X and Y are i.i.d. random variables (normal or otherwise), E((X + Y)/2) = (E(X) + E(Y))/2 = E(X) — the expected value of the average is the same as the expected value of either variable. But E(max{X, Y}) > E(X), as long as the variation is nonzero.
I think I get what you’re saying, but the way you put it is very confusing. Your point is that if you do parallel lookup, you have to wait for both lookups to finish before you proceed in some cases, right? And that’s slower than only having to wait for one. (In some cases you can presumably proceed after you get the first response, like if you prefer IPv6 and the AAAA response returns first with a valid address.)
Why can’t servers just return both A and AAAA records in the same response? DNS servers already do something like that with glue records, right? Then they could return the same packet twice and you could proceed as soon as you get the first. Or would that violate specs and/or break clients?
@simetrical – absolutely right about max not avg. Sorry about that, corrected. As for why servers don’t do A + AAAA records together, I’m not entirely sure, but I suspect it mostly has to do with the fact that not all servers can be simultaneously upgraded, and clients have no way of knowing if an A/AAAA request is handled by a server a-priori. But I haven’t studied DNS options much.
Even if clients have no way of knowing if the server will return both A and AAAA records, they can still make both the A and AAAA queries in parallel. If the server only returns what was queried, it will be slower, as now. If the server returns both, you get two identical responses that each include both the A and AAAA, and you can always proceed after the first response, so latency doesn’t have to be any worse than for a single query. You’d be making two queries instead of one, but that’s no worse than the status quo.
Of course, if servers started doing this, clients could eventually start sending only one query if they guessed only one was needed. Normally clients will only be making requests to one to three recursive nameservers anyway, so they could just remember if those servers return A+AAAA or not and only send one query if they do. If the client guesses wrong, the worst case is it needs to make a second query in serial.
I’d be entirely unsurprised if all this would be harder to deploy than I’m making it sound, though.
Pingback:Google: Don't Use IPv6, For Now | ConceivablyTech
This data looks bad, but it does not prove that there is substantial performance impact on real page load times. In many cases Chrome’s DNS prefetching makes these delays completely irrelevant, and in many other cases, DNS lookups are already cached locally by the OS, which again, removes this penalty completely. If you want to make a recommendation for users on whether to use IPv6 or not, then you should look at data for page load times, not data on DNS lookups.
Until that data is available and shows impact, any claim that IPv6 substantially slows down internet connections is misleading.
Also, the problem with doing the requests in parallel is that a small percentage of buggy home gateways will simply choke. They will either fail to respond to one of the requests, causing a timeout that’s measured in seconds, or they will conflate the answers, returning invalid IP addresses. So you can’t just do them in parallel, you have to stagger them a bit, where “a bit” depends on which home gateway you have and probably cannot be determined without probing.
@Lorenzo: No, this data is not misleading. This data is a correct reflection of what real users are experiencing right now. DNS lookups are slower absolutely slower with IPv6. Worse – even if you’re not using IPv6, simply having it enabled on your system makes EVERYTHING slower. I made no claims about how this affects page load time, but you and I both know that slower DNS times do not increase your page load times. Further, you and I also know that DNS pre-resolution does not eliminate DNS lookup times either (not by a long shot!)
Lastly, the data does not suggest that this is isolated to outliers or a “small percentage of buggy home gateways”. I can show you the absolute data, and it shows quite clearly that all users from the fastest 10% to the slowest 10% are seeing substantially increased lookup times.
I know there are folks that want to push IPv6 at any cost. There are benefits to IPv6, but there are also costs. Just because you think the benefits outweigh the costs does not make the costs go away.
1. I think it is misleading to have the Y-axis of your graphs start at 20ms.
2. You haven’t delved into _why_ DNS queries for AAAA records are slower. Is it just that the nameservers along the way don’t have the answer cached, or the client is firing up a Teredo tunnel to do the query over IPv6, or what ?? I can’t imagine an authoritative nameserver for a domain taking any longer to actually generate the answer being sent.
3. From your graph, the difference in average response times for Windows users is ~20ms. Will users notice that in page load times? Is the DNS penalty only for the first page loaded from a site?
Performance sensitive users should also be aware that sometime real soon, Large Scale NAT will degrade their IPv4 network experience to below that of IPv6. IPv6 is already faster for a few sites.
Mike, I think you’re missing the point I was trying to make.
I’m not disputing that the data shows that DNS lookups are slower when IPv6 is enabled. I’m saying that if the time spent waiting for DNS lookups is a small percentage of page load times, then the effect on page load times of even substantially slower DNS lookups will be very small.
For example, suppose the average page load time is 5s, and that you only need one DNS lookup. Take the worst case, Mac, where you go from ~35ms to ~90ms. Wow, a 146% increase! That’s horrible, right? Well, not really – because if your page load time is 5s and you have just one DNS lookup, this means that a page that previously loaded in 5000ms now loads in 5055ms. That’s a 1.1% performance penalty. Doesn’t look so bad now
More in general, if DNS lookups make up X fraction of page load times, then if DNS queries are S times slower (e.g., S=2.46 in your Mac data), you’ll have a a total increase in your page load time of (S – 1) X. So if DNS queries are even 10% of your page load time (which seems very high), and they’re 2x slower, total page load time will increase by 10%. This is really just Amdahl’s law.
A simplistic way of measuring true impact would be to find out how many DNS lookups N there are in the average page load (N = 5? 10?) and divide the average page load time T (5s? 10s?) by the total time spent in DNS (say N * 35ms on Mac). If T = 5, we get X = 0.035 (3.5%), and if S = 2.46, then we get approximately 5%. In reality, it’s probably a little less, because Chrome does DNS prefetching. Also, this simplistic model assumes that DNS lookups completely block everything else, which is not true because other connections are free to download data in the background, the renderer is free to render, and so on.
Do you have data for what N and T are likely to be?
@Lorenzo – On Chrome we fight to get a 50ms decrease in latency any way we can get it. Whether it’s backup sockets, DNS prefetching, SPDY, socket late binding, preconnect, or SSL False Start – every delay we can remove is worth it. You can pretend that it is OK for IPv6 to be slow, but that will never be my mindset.
The average number of domains per page is now 9, with many sites using more than 20. While it may only be 60ms for each request, that represents a worst case of 60 * 9, which is nearly a half a second. Multiply that by the number of unique sites the user visits, and you’ll realize that this allegedly tiny delay is actually measured in seconds per user per day. Ouch! And I haven’t even started talking about how IPv6 increases your odds of hitting packet-loss induced stalls…
The benefits of reduced DNS time have been witnessed by many, and since Chrome introduced DNS prefetching, Firefox, Safari and IE have all followed suit. This stuff really does matter, IPv6 or not.
@jonn.a.mann: I can speculate why the AAAA records are slower, but it doesn’t really matter. These are measured results, and they are very real. I encourage other browsers to make similar measurements to verify these findings.
If you’ve got data to show that IPv6 sites are faster than IPv4 ones, I’d love to see it.
I’m surprised by the pushback on this simple measurement from the IPv6 proponents. Would you really like me to measure IPv6 vs IPv4 PLT from Chrome? If you don’t like this number, you’re *really* going to dislike the PLT number! 🙂 What will you do then?
Mike: if you have the data, then please do publish it.
For example, it would be great to see what median and average page load times are over IPv4 and IPv6 for, say, http://www.google.com. Do you have a way of calculating this data?
Do you have a way to measure the quantity of the AAAA lookups compared to A lookups for the same hostnames ?
I’ve a (pure speculation) theory that AAAA lookups are performed much less frequently (~<1/100?) – so the results are less often in the local recursive name server cache when needed – moving the average up.
@mike: The reason why AAAA records are slower does matter. If you know the reason, you can take steps to fix it.
For example, why are A lookups faster on Macs rather than Windows?
Would you advise performance-sensitive users to switch from Windows to Mac?
Is it because Mac users go to different websites that Windows users? – re-standardise test to measure same-site response.
Is it because OSX has a shorter/better Domain-suffix search-path algorithm? – change Windows settings and/or algorithm.
Is it because Mac users also pay more money for better home networking? etc etc
Without knowing, because you haven’t said, when using IPv6, are these computers doing
query a http://www.facebook.com => answer
query aaaa http://www.facebook.com => NXDOMAIN
query aaaa http://www.facebook.com.example.com => NXDOMAIN
query aaaa http://www.facebook.com.com => NXDOMAIN
The way to make this go faster is to add a AAAA for http://www.facebook.com !!!
[ Websites who want their pages (for those users that have IPv6 enabled) to load faster, should setup AAAA records ]
There are some anecdotal reports of pages loading faster over IPv6 than IPv4.
I saw an x-y graph, but don’t remember where …
Take a look at
http://mnlab-ipv6.seas.upenn.edu/monitor/pg41.html
“Fig-4.1 shows the change with time of α for categories Top-10, Top-100, Top-1K, Top-10K, Top-100K, and Top-1M, respectively, where α stands for the percentage of sites reachable via both IPv4 and IPv6 and which have a lower average download time via IPv6.”
From “See Raw Data”, the 11-06-22 reading for “total” says 35.07% of websites load faster over IPv6.
John
@john: of course it does matter for fixing it; the bulk of the debate here was about whether they are slower or not. I have many theories, but they need to be tested before claiming they are true.
As for graphs claiming to show IPv6 faster than IPv4, bring them on. I have yet to see any such data… Don’t forget to measure DNS in your study, because you’ll have to overcome that handicap.