In bug 1498663 I (after discussion with Dragana) proposed racing alt-svc connections to multiple alt-svcs for a particular origin. We don't currently store more than one alt-svc for an origin, and there's some trickery around the Alt-Used request header that make the racing a relatively invasive change. However, looking at our telemetry (which isn't great), I can see that of all our transactions, only 0.1-0.2% of all transactions ever use an alt-svc (and that the vast majority of those are opportunistic encryption alt-svcs). Looking at our telemetry around quic alt-svc, that number could increase pretty dramatically, though, as around 26% of all requests receive an alt-svc header that contain quic as an option. We don't (yet) support quic, but we will in the future. OK, so we can assume alt-svc use will increase pretty dramatically. However, throwing another wrench into that, is... do we ever, in practice, receive alt-svc headers/frames that would point to multiple hostnames as options? Looking at my own local telemetry (anecdata, I know) and requests, pretty much all of those that receive alt-svc for quic are requests to google, and those never change hostname (indeed, they don't contain a hostname in the alt-svc response). So, we would never have multiple alt-svc hostnames to race, if the data for this pans out globally to be similar to mine. So, let's collect some data about how often we receive an alt-svc response that fits the following two criteria - (1) contains an explicit hostname, and (2) makes a change to the hostname in a cached alt-svc entry. If the number above is low enough, it would seem that we probably shouldn't spend the effort and code complexity to store & choose from multiple alt-svc destinations for an origin at all, let alone to race them.
Right now, we have no idea how often an origin may offer us multiple alt-svc options. As we are considering racing multiple alt-svc connections (if they're available), it would be good to know how often we actually have (or would have, were we to store them) multiple options available. It would also be good to know how often an origin may change the target of its alt-svc mapping (even if there is only one target), as changes in target may make it useful to store/race multiple targets, as well.
Comment on attachment 9017589 [details] altsvc-data-review-request.txt 1) Is there or will there be **documentation** that describes the schema for the ultimate data set available publicly, complete and accurate? Yes, in Histograms.json. 2) Is there a control mechanism that allows the user to turn the data collection on and off? Yes, telemetry setting. 3) If the request is for permanent data collection, is there someone who will monitor the data over time?** Yes, Nicholas Hurley. 4) Using the **[category system of data types](https://wiki.mozilla.org/Firefox/Data_Collection)** on the Mozilla wiki, what collection type of data do the requested measurements fall under? ** Category 1. 5) Is the data collection request for default-on or default-off? Default ON, all channels. 6) Does the instrumentation include the addition of **any *new* identifiers** (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)? No. 7) Is the data collection covered by the existing Firefox privacy notice? Yes. 8) Does there need to be a check-in in the future to determine whether to renew the data? No, permanent.
Attachment #9017589 - Flags: review?(francois) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/b6780702981d Better telemetry for alt-svc headers seen in the wild. r=francois,valentin
https://hg.mozilla.org/projects/larch/rev/b6780702981d863bfd913ca404d5b5209b952066 Bug 1499149 - Better telemetry for alt-svc headers seen in the wild. r=francois,valentin
You need to log in before you can comment on or make changes to this bug.