Should we do an experiment?

What metric would you seek to optimize? HTTP/3 usage? ECN usage? Connection establishment time?

Should we do an experiment?

We can. That said, having done one myself now, I am not sure it is worth the bureaucratic overhead.

Given that Firefox Nightly is a small population only, and given the overhead of an experiment, how about we enable ECN on Firefox Early Beta first. Rolling out to more devices gives us higher confidence in the percentage of ECN black holes seen by Firefox users. In case the percentage of black holes is still relatively high, we either (a) do an experiment or (b) make a change like the one suggested above.

What metric would you seek to optimize? HTTP/3 usage? ECN usage? Connection establishment time?

Metrics worth monitoring:

• Number of HTTP responses by version via https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/metrics/http_response_version . A drop in http3 might signal http3 connection establishment latency increase and thus http2 winning over http3.
• Number of blackholed connection attempts via https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/metrics/networking_http_3_ecn_path_capability
• Connection establishment time via https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/metrics/network_sup_http3_tcp_connection

If I understand correctly our initial PTO should be ~100ms. Thus ~2% of HTTP3 connections get delayed by 300ms. I would assume most of these ~2% thus loose the race to a concurrent HTTP2 connection attempt

Once we no longer do time threshold based loss detection before the first ACK (i.e. #2492), this is wrong. Our initial RTT is 100ms. Thus the first PTO is 100ms + 4*rttvar where rttvar is RTT/2, i.e. 300ms. The second PTO is 600ms. The third PTO is 1200ms. In sum, this is 2100ms before we detect an ECN blackhole and thus stop marking with Ect0.

See changes to handshake_delay_with_ecn_blackhole test in #2492.

We are currently rolling out ECN support to Firefox Early Beta. Unless that reveals significantly other numbers than shared above, I think we need to take action before going to Firefox Release.

Options thus far:

• Reduce the number of MAX_PATH_PROBES with ECN.
• Reduce the initial PTO time with ECN.
• Only start marking packets after the handshake is done.

As a quick fix, I would suggest doing either or both of your first two bullets. If we then still see issues, maybe do the third bullet.

I don't find reports by others with such high ECN black-hole rates (i.e. > 2%). Thus I slightly doubt the metrics I introduced.

We previously reduced the set of connection failures we consider an ECN blackhole via https://phabricator.services.mozilla.com/D239884.

I propose restricting this set even further, only considering a path to be an ECN blackhole, if the connection handshake succeeds after ECN black-hole detection, i.e. without ECN marking. Linking https://phabricator.services.mozilla.com/D244507 here for the record.