Distributed scanning of targets

[TaaviE]

It would be really nice if quic-tracker could also have information about the general accessibility of QUIC hosts from different ASNs, there's really no public information about that available online and the data could become really valuable for providing better service to people (for ex. selectively not sending Alt-Src to clients or e-mailing ISPs that seem to block QUIC).

[mpiraux]

Hello,
This is a very interesting perspective!

A very simple approach is to connect to a test server from different hosts distributed across the Internet.
A client that is able to complete the handshake, and possibly exchange some data with the test server reports its source IP as QUIC-enabled. To achieve this several components are required.
First one or more test servers are required. QUIC-Tracker only behaves as a client for the moment. Then several clients connecting to the test server and reporting the test results must be placed in various networks. We could ship a ready-to-go and reduced version of the test suite on desktop and mobile clients for this purpose.
I think the QUIC-Tracker trace format is rich enough to convey all the information needed to diagnose basic issues (i.e. no packets received by the client, the handshake failed, no application data could be exchanged). It is the real advantage of using a test suite instead of a regular QUIC client with some added scripting.

Then scope of the scan can be expanded in several dimensions. A subset of the tests could be run against the test servers, restricted to the tests that produce different wire images. These tests could be testing Version Negotiation, 0-RTT Handshake and 0-RTT data, New Connection IDs, Connection Migration, Key Update and possibly Spin Bit. This could help to diagnose a broad ranges of issues that could arise beyond the simple UDP blockage.

As a side comment:

for ex. selectively not sending Alt-Src to clients or e-mailing ISPs that seem to block QUIC).

Currently the general consensus when using QUIC is to race both TCP and QUIC and use what ever wins the race. See my notes on the recent Facebook talk opening the QUIC workshop at CoNEXT 2018 which details the first large-scale deployment of (IETF-)QUIC.
I think the reporting approach is the way to go for enabling QUIC in the "tail ASNs" that may not be proactive in the deployment of QUIC.