Bugzilla

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).  1781075 and 1781078 are both related but slightly orthogonal to this.

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.