Open Bug 1498663 Opened 4 years ago Updated 5 months ago
Race connections to multiple altsvcs for the same origin
When using an alternate service, we should so something like we will do in bug 1498661 for regular DNS lookups. That is, we should fire off connections to two different altsvcs for the same origin (if more than one is available). Right now, we don't even keep information for two altsvcs, so this is blocked by the work in 1493724. Additionally, we will need to come up with a proper way to set the Alt-Used header in the request *after* the connection has been set up, as we won't know when racing which altsvc entry is used until after that happens.
OK, telemetry hasn't been around long (and according to telemetry.m.o as I write this, data from post-Oct 11 isn't available, and telemetry landed on the 17th, so I can't see what little data there should be), but I was able to poke around in httparchive data to get a sense for how things are with alt-svc usage in the real world. This should (hopefully) give us a clue as to whether or not it's useful to even store 2 alt-svc alternatives for a host, let alone race them should they exist. Here's the (relatively) quick rundown: I looked at data from around 10 million requests from httparchive data from the Oct 2018 dataset (total number of requests in the dataset is around 132 million - it was going to take weeks for me to dig through all the data). There are a little under 2 million hostnames represented in the data I processed. Of those, only a little over 3000 (so around 0.1%) responded with alt-svc at all. Of those that responded with alt-svc, 99.7% of them responded with only one alternate (0.3% of hosts responding with alt-svc present multiple alternates). Things get slightly more complex when you look at requests (not hosts) that had an alt-svc header. Around 14% of all requests had any alt-svc response, and of those, around 65% responded with only one alternate (35% of requests with alt-svc present have multiple alternates). That means around 9% of all requests respond with one alternate, and around 5% of all requests respond with multiple alternates. About half of both hosts and requests that respond with multiple alternates are google. However, even within google traffic, the vast majority of both hosts and requests only respond with one alternate. I haven't seen a single response with multiple alternates that didn't resolve down to one of the big CDNs. If I'm being honest, I'm not really convinced that racing alternates is going to gain us a lot here. For one, we will already have TCP connection racing once bug 1498661 is done. That gets us a long way to avoiding things like lost SYNs and bad paths to particular IPs. Combine that with the fact that it's CDNs serving these multiple alternates, and the chances of anything incredibly bad happening on the path to one alternate that wouldn't affect the other alternate(s) becomes, I think, pretty small. At the very least, I don't think racing alternates is something we need to prioritize any time soon, especially with the added work that would need to be done to store multiple alternates to begin with, plus deciding which one to use if we aren't racing for some reason, and setting the Alt-Used header at a late enough point that we know which alternate was selected of the raced ones (which is not particularly straightforward, given the current ordering of things). That said, this prioritization could change some time in the future, once ietf-quic takes off, but even that may mostly consist of single-option alt-svc headers.
Dragana, ni?ing you here just to put the info in comment 1 on your radar, I don't have any particular question. Of course, you're more than welcome to weigh in, if you want.
But you still have the original origin and the alternative one you can race? It would be interested to know how often they offer the same protocol, and how often it advertising a different protocol? This is hard to get from the data.
Assignee: u408661 → nobody
You need to log in before you can comment on or make changes to this bug.