1782716 - RFC: Necko should use HTTPS RR information to make concurrent connections.

Status: NEW

(Core :: Networking: DNS, enhancement, P3)

Description

[Dennis Jackson]

HTTPS RR records typically offer many different possible connection hints. For example, we might receive the following record:

      {
        "class": "IN",
        "name": "foo.org",
        "priority": 1,
        "svcparams": {
          "alpn": [
            "h2",
            "h3",
          ],
          "ipv4hint": [
            "104.26.6.61",
            "104.26.7.61",
            "172.67.73.111"
          ],
          "ipv6hint": [
            "2606:4700:20::681a:63d",
            "2606:4700:20::681a:73d",
            "2606:4700:20::ac43:496f"
          ]
        },
        "target": ".",
        "ttl": 300,
        "type": "HTTPS"
      }

This record indicates the availability of three different application layer protocols (http/1.1 - since no-default-alpn is absent, h2, h3) across two different transports (443/tcp, 443/udp) and six different endpoint identifiers for a total of 12 possible connections (since http/1.1 and h2 will run on the same transport). There are also the 4 possible connections to the origin (ipv4,ipv6, 443/tcp, 443/udp).

At present, Necko will examine these options and select its preferred transport (e.g. h3 if available) and start that connection only plus a fast fallback later. I'm unsure if the ipv4-ipv6 are then both raced using the hints from the record.

Instead, I think racing both h1+h2 and h3 connections to both an ipv4 and ipv6 endpoint (4 total connections) makes sense. After an appropriate timeout (500ms?), the next set of connection options should be launched in parallel. If ECH is available for some of the records and enabled in Firefox, we should follow the existing logic (consider all configs with ECH first, then fallback to the origin / non-ECH configs).

On the implementation level, this would probably involve splitting the current priority queue into two (one for h1/h2 and one for h3) and ensuring that the ip hints are correctly propagated and selected from (they might be already, I didn't check). Bug 1781075 and bug 1781078 are both related but slightly orthogonal to this.

Comment 1

[Dragana Damjanovic [:dragana]]

HTTPS RR are mostly useful for 3 things:

• indication to use HTTPS which we respect,
• discovering ECH - I think our behavior with ECH is fine,
• discovering HTTP/3:
  • If we discover that the service is accessible using HTTP/3 we try to use it and fall back if it is not accessible. The backup connection will be started with 250ms delay.
    • HTTP/3 is not accessible in ~5% of connections, that is not a lot and
    • if the connection using HTTP/3 fails HTTP/3 will be disabled for the origin
    • if it is persistently not accessible, HTTP/3 will be disabled for the session.
    • Considering the above 250ms delay is fine, since it is not happening that often and we give HTTP/3 a headstart in cases some packets get lost. I do not think we should race HTTP/3 with HTTP/2 or 1, I think giving HTTP/3 a headstart is good.

We are not racing ipv4 and ipv6 for HTTP/3 - that can be improved.
For TCP we do have fall back mechanism that is available for all connections and in case the first connection was ipv6 the second will use ipv4. The delay for the fallback connection is also 250ms. I am not sure if racing will be useful, maybe. We need telemetry measurements to see if we really have a problem we need to solve. This backup connection was introduced to solve long delays if SYN packets are lost. Maybe ipv6 vs ipv4 could have a short delay, but a headstart is useful as well here.

We try only one combination from HTTPS RR record and if it fails we fall back to connecting to the origin directly. I need to look into telemetry to see if we actually have a problem.

IP address hints are used if available.