Subject: [quicwg/base-drafts] Better describe the use of Preferred Address (#3354)

From: Kazuho Oku <[email-masked]>
Date: Thu, 16 Jan 2020 18:52:58 -0800

This PR changes the following:
* Better clarifies when the client should initiated migration to the preferred address (i.e., when the handshake is *confirmed*).
* States that an unused active connection ID should be used, rather than stating that the connection ID provided by TP.preferred_address have to be used. This fixes the ambiguity regarding the use of CID in relation to CID retirement. As noted in https://github.com/quicwg/base-drafts/issues/3353#issuecomment-575396028, this change does not require modification of existing code.
* Expand the explanation of the fields contained in TP.preferred_address.

closes #3353.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3354

-- Commit Summary --

  * specify the timing clearly
  * relax the requirement so that it works well with CID retirements
  * clarify what `Connection ID` and `Stateless Reset Token` fields are
  * refer to the section that talks about issuing CIDs

-- File Changes --

    M draft-ietf-quic-transport.md (20)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3354.patch
https://github.com/quicwg/base-drafts/pull/3354.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 16 Jan 2020 18:54:14 -0800

@kazuho pushed 1 commit.

28190f809274c0da16680413886edc5625d9510d  less verbose

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/a029b07750e5c585322383f00773833a3eaf73ad..28190f809274c0da16680413886edc5625d9510d

---

From: Mike Bishop <[email-masked]>
Date: Fri, 17 Jan 2020 10:07:55 -0800

MikeBishop commented on this pull request.

I'm not totally sold on dissociating the CID from the preferred address, but the rest of this looks like a net improvement.  I'll address that one the issue.

> @@ -4635,8 +4634,12 @@ preferred_address (0x000d):
   transport parameter is only sent by a server. Servers MAY choose to only send
   a preferred address of one address family by sending an all-zero address and
   port (0.0.0.0:0 or ::.0) for the other family. IP addresses are encoded in
-  network byte order. The CID Length field contains the length of the
-  Connection ID field.
+  network byte order. The Connection ID field and the Stateless Reset Token
+  field contain the alternative connection ID that is assigned the sequence
+  number of one ({{issue-cid}}). Having them bundled with the  preferred address

```suggestion
  number of one ({{issue-cid}}). Having them bundled with the preferred address
```

> @@ -4635,8 +4634,12 @@ preferred_address (0x000d):
   transport parameter is only sent by a server. Servers MAY choose to only send
   a preferred address of one address family by sending an all-zero address and
   port (0.0.0.0:0 or ::.0) for the other family. IP addresses are encoded in
-  network byte order. The CID Length field contains the length of the
-  Connection ID field.
+  network byte order. The Connection ID field and the Stateless Reset Token
+  field contain the alternative connection ID that is assigned the sequence
+  number of one ({{issue-cid}}). Having them bundled with the  preferred address
+  ensures that there would be at least one unused active connection ID when the

```suggestion
  ensures that there will be at least one unused active connection ID when the
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#pullrequestreview-344750056

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 17 Jan 2020 13:46:29 -0800

@kazuho pushed 1 commit.

b8c2408fcfb984d85ea59a1a163e5089b0782254  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/28190f809274c0da16680413886edc5625d9510d..b8c2408fcfb984d85ea59a1a163e5089b0782254

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 17 Jan 2020 13:46:38 -0800

@kazuho pushed 1 commit.

ac42f929f75403f2da2b5dbd244a37df31590da3  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/b8c2408fcfb984d85ea59a1a163e5089b0782254..ac42f929f75403f2da2b5dbd244a37df31590da3

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 18 Jan 2020 17:52:37 -0800

@kazuho pushed 1 commit.

ea7c75066c52a5238508fddfbdaa6d5e50439d57  require clients to send RETIRE_CID with sequence number of 0 or 1, when the serever uses TP.preferred_address

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/ac42f929f75403f2da2b5dbd244a37df31590da3..ea7c75066c52a5238508fddfbdaa6d5e50439d57

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 18 Jan 2020 17:54:52 -0800

@MikeBishop Thank you for your suggestions.

Based on the discussion on #3353, I've pushed ea7c750, that states that a client SHOULD retire either of the two CIDs when the server uses TP.preferred_address.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#issuecomment-575957286

---

From: Eric Kinnear <[email-masked]>
Date: Sun, 19 Jan 2020 10:30:19 -0800

erickinnear approved this pull request.

+When the client finishes migrating to the preferred address, it retires the
+connection ID that was used for the original path ({{retiring-cids}}).
+Similarly, a client that continues using the original server address SHOULD
+retire the connection ID provided by the preferred_address transport parameter.
+Retirement of either of these connection IDs notifies the server the server

```suggestion
Retirement of either of these connection IDs notifies the server of the
```

+When the client finishes migrating to the preferred address, it retires the

This is not currently required anywhere that I can find, do you want to make this a "SHOULD retire"?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#pullrequestreview-345017627

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 14:19:41 -0800

@kazuho pushed 1 commit.

8201bd67d2da9ff7ff785cc8b5a29dff5669667d  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/ea7c75066c52a5238508fddfbdaa6d5e50439d57..8201bd67d2da9ff7ff785cc8b5a29dff5669667d

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 16:31:28 -0800

@kazuho pushed 2 commits.

ed4495b759f4d70f713752e363f9e061af03c258  wip
c283314ce2b19aabe05cf09c951daa7788f2f4ed  a previously used CID cannot be used on a new path (opened for migration or probing)

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/8201bd67d2da9ff7ff785cc8b5a29dff5669667d..c283314ce2b19aabe05cf09c951daa7788f2f4ed

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 16:38:16 -0800

@kazuho pushed 1 commit.

d6d3b17098156e0091a98bb1bbbcff60f0c12313  update 5.1.2 too

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/dc1c5f7fc0e72ad2ceac94ba1b4f457f99110277..d6d3b17098156e0091a98bb1bbbcff60f0c12313

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 16:41:16 -0800

kazuho commented on this pull request.

That's a keen observation. I had assume that we'd state that:
* a connection ID that was used on one path MUST NOT be used on a path created by migration
* a connection ID that becomes unusable SHOULD be retired

But surprisingly, we did not. As these requirements are common to ordinary connection migration and migration by preferred address, I've changed the sections that are shared by the two.

PTAL at commits 8201bd6 and dc1c5f7.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#discussion_r368337761

---

From: Martin Thomson <[email-masked]>
Date: Sun, 19 Jan 2020 21:42:45 -0800

martinthomson commented on this pull request.

Thanks for doing this.  This text certainly needed a few refinements.

> @@ -2194,11 +2194,13 @@ linked by any other entity.
 At any time, endpoints MAY change the Destination Connection ID they send to a
 value that has not been used on another path.
 
-An endpoint MUST use a new connection ID if it initiates connection migration as
-described in {{initiating-migration}} or probes a new network path as described
-in {{probing}}.  An endpoint MUST use a new connection ID in response to a
-change in the address of a peer if the packet with the new peer address uses an
-active connection ID that has not been previously used by the peer.
+An endpoint MUST use a new connection ID when it initiates connection migration
+as described in {{initiating-migration}} or {{preferred-address}}, or when it
+probes a new network path as described in {{probing}}, and MUST NOT reuse

The run-on sentence here could be two sentences.

```suggestion
probes a new network path as described in {{probing}}. Endpoints MUST NOT reuse
```

...but I'm not seeing what the new content here does.  It appears to just be a restatement of the previous clause.

> @@ -1036,9 +1036,9 @@ be used again and requests that the peer replace it with a new connection ID
 using a NEW_CONNECTION_ID frame.
 
 As discussed in {{migration-linkability}}, each connection ID MUST be used on
-packets sent from only one local address.  An endpoint that migrates away from a
-local address SHOULD retire all connection IDs used on that address once it no
-longer plans to use that address.
+packets sent from only one local address, and MUST NOT be used across multiple
+paths that are opened intentionally.  An endpoint SHOULD retire connection IDs
+as they become unusable.

This new text is less accurate.  It is potentially always possible to reuse connection IDs, but what matters is whether the endpoint forsees use of the connection ID.  The original text is probably not as good as it could be, but that seems unrelated to the stated goal of the PR.

As this is a restatement of the original text in another section, I would prefer to keep this terse.  In fact, I would not use normative language and instead say:

> As discussed in {{blah}}, endpoints limit the use of a connection ID to a single network path where possible.  Endpoints SHOULD retire connection IDs when no longer actively using the network path on which the connection ID was used.

+When the client finishes migrating to the preferred address, it retires the
+connection ID that was used for the original path ({{retiring-cids}}).
+Similarly, a client that continues using the original server address SHOULD
+retire the connection ID provided by the preferred_address transport parameter.
+Retirement of either of these connection IDs notifies the server of the
+address the client has chosen.

This creates a much stronger inference than I think we ever formally documented, though it is a reasonable one for sure.  If your intent is that the server never see data on the old path, then say that instead:

> Once a client has migrated successfully to a network path that uses a server preferred address, it MUST NOT migrate to a path using the address that was used during connection establishment.

Otherwise, the inference you are giving the server to make here is without any support.  Once you say this, you can drop this text.

> @@ -4635,8 +4642,12 @@ preferred_address (0x000d):

New paragraph here please.
```suggestion
  network byte order.
  
  The Connection ID field and the Stateless Reset Token
```

> @@ -4635,8 +4642,12 @@ preferred_address (0x000d):

```suggestion
  field contain an alternative connection ID that has a sequence
```

> @@ -4635,8 +4642,12 @@ preferred_address (0x000d):

```suggestion
  number of 1 ({{issue-cid}}). Having these values bundled with the preferred address
```

> @@ -4635,8 +4642,12 @@ preferred_address (0x000d):
   transport parameter is only sent by a server. Servers MAY choose to only send
   a preferred address of one address family by sending an all-zero address and
   port (0.0.0.0:0 or ::.0) for the other family. IP addresses are encoded in
-  network byte order. The CID Length field contains the length of the
-  Connection ID field.
+  network byte order. The Connection ID field and the Stateless Reset Token
+  field contain the alternative connection ID that is assigned the sequence
+  number of one ({{issue-cid}}). Having them bundled with the preferred address
+  ensures that there will be at least one unused active connection ID when the
+  client initiates migration to the preferred address. The CID Length field
+  contains the length of the Connection ID field.

I'd drop the last sentence.

> @@ -2251,16 +2253,21 @@ transport parameter in the TLS handshake.
 Servers MAY communicate a preferred address of each address family (IPv4 and
 IPv6) to allow clients to pick the one most suited to their network attachment.
 
-Once the handshake is finished, the client SHOULD select one of the two
+Once the handshake is confirmed, the client SHOULD select one of the two

👍 Do we need a citation here too?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#pullrequestreview-345085453

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:11:09 -0800

The problem with the existing text is that while it says that a new connection ID MUST be used when "initiating" a migration, or probing, it does not forbid reuse of a CID (that has previously used on a different path) once the path is being validated.

That's is why I added the "MUST NOT" without splitting the sentence.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#discussion_r368394945

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:12:12 -0800

@kazuho pushed 1 commit.

0672237d9198dc2d55438b4960c09aa9c8ab8b2a  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/d6d3b17098156e0091a98bb1bbbcff60f0c12313..0672237d9198dc2d55438b4960c09aa9c8ab8b2a

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:12:23 -0800

@kazuho pushed 1 commit.

12f8fb56ee94836281f41748c62b5ef1220f4d7b  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/0672237d9198dc2d55438b4960c09aa9c8ab8b2a..12f8fb56ee94836281f41748c62b5ef1220f4d7b

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:18:17 -0800

@kazuho pushed 1 commit.

31584fd9c2d0bcdf39508aef1ef011acee9eff89  refer to QUIC-TLS for the definition of "handshake confirmation"

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/12f8fb56ee94836281f41748c62b5ef1220f4d7b..31584fd9c2d0bcdf39508aef1ef011acee9eff89

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:18:38 -0800

Done in 31584f.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#discussion_r368396805

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:21:44 -0800

@kazuho pushed 1 commit.

23bddd3e4db73eb945211f1da5eb86161f705d40  split the paragraph, drop description of CIDL

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/31584fd9c2d0bcdf39508aef1ef011acee9eff89..23bddd3e4db73eb945211f1da5eb86161f705d40

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:22:25 -0800

Done in 23bddd3e, however I do not see xml2rfc splitting the paragraph. Maybe because it's part of a list?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#discussion_r368397714

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:28:41 -0800

@kazuho pushed 1 commit.

f268ac457d41e6f2519bc00bca4ed392f12ada67  do not have two paragraphs talking what a client does when migration succeeds (or fails)

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/23bddd3e4db73eb945211f1da5eb86161f705d40..f268ac457d41e6f2519bc00bca4ed392f12ada67

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:30:11 -0800

Yeah though not a "MUST NOT", that is already stated in the previous paragraph. That said, I think it would be better to merge the two paragraphs, as having two paragraphs describing what a client should do went migration succeeds (or fails) is confusing.

PTAL at commit f268ac4.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#discussion_r368399544

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:32:04 -0800

@kazuho pushed 1 commit.

7bac2b7935175e5afff08c5a0146dc73dd26c052  wordwrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/f268ac457d41e6f2519bc00bca4ed392f12ada67..7bac2b7935175e5afff08c5a0146dc73dd26c052

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jan 2020 23:34:55 -0800

@martinthomson Thank you for the review. I think I've made necessary changes, or have responded to your comments. Please take a look and let me know what you think.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#issuecomment-576143926

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Jan 2020 00:34:36 -0800

The "MUST NOT" stands on its own in that case:

> An endpoint MUST NOT use a connection ID on a given network path if it has used the same connection ID to send packets on another network path.

The intended meaning of "new" in this text is to imply "previously unused", which might be more clearly stated as:

> An endpoint MUST use a connection ID that it has not previously used when it initiates connection migration ({{initiating-migration}}), including using a preferred address ({{preferred-address}}).  Similarly, an endpoint MUST use an unused connection when probing a new network path ({{probing}}).   An endpoint MUST use a previously-unused connection ID in response to a change in the address of a peer if the packet with the new peer address uses an active connection ID that has not been previously used by the peer.  An endpoint MUST NOT [...as above].

This covers all the existing reasons to use a previously unused connection ID.  You could restate as a list instead, I guess:

> An endpoint MUST use a new connection ID when it:
> * migrates to a new network path ({{initiating-migration}}), including migrating to a server's preferred address ({{preferred-address}});
> * probes a new network ({{probing}}); or,
> * sends a packet on a new network path as a result of responding to the migration of a peer, where the peer uses a connection ID that has not been used on another path.
>In all cases, an endpoint MUST NOT use a connection ID on a given network path if it has used the same connection ID to send packets on another network path.

 If path validation succeeds, the client SHOULD immediately begin sending all
-future packets to the new server address using the new connection ID and
-discontinue use of the old server address.  If path validation fails, the client
-MUST continue sending all future packets to the server's original IP address.
-
+future packets to the new server and discontinue use of the old server address,
+and retire the connection ID that was used for the original path
+({{retiring-cids}}).  If path validation fails, or if the client decides not to
+migrate to the preferred address, it MUST continue sending all future packets to
+the server's original IP address, and retire the connection ID provided by the
+preferred_address transport parameter.  Retirement of either of these connection
+IDs notifies the server of the address the client has chosen.

Let me try to be clearer about my objection to this last sentence.

This implies a semantic to the retirement of connection IDs that is not already defined.  It says that in addition to releasing the resource, the server can say definitively that those other network paths won't be used.  But this is misleading because retiring CID 1 does not prevent CID 4 from being used on that path.  Nothing says that the connection IDs sent in NEW_CONNECTION_ID have to be used on one or other path.  Better to keep the requirement where it is: don't migrate back if you use a preferred address.  

Yes, that means that servers can't be sure of behaviour of clients here, but they can use the destination address to confirm acceptance of the preferred address or not.  That should suffice.

> @@ -4635,8 +4640,13 @@ preferred_address (0x000d):
+  network byte order.
+
+  The Connection ID field and the Stateless Reset Token field contain an

This might fix the formatting issue.

```suggestion
: The Connection ID field and the Stateless Reset Token field contain an
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#pullrequestreview-345140615

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 20 Jan 2020 01:09:14 -0800

@kazuho pushed 1 commit.

7f3477467feb5d0d31bfa55361378859a027e2da  add colon

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354/files/7bac2b7935175e5afff08c5a0146dc73dd26c052..7f3477467feb5d0d31bfa55361378859a027e2da

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 20 Jan 2020 01:11:31 -0800

Thank you for the suggestion. Done in 7f34774.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#discussion_r368434905

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 20 Jan 2020 01:12:19 -0800

Thank you for the suggestion. Done in 7f34ff4.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#discussion_r368435272

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 20 Jan 2020 01:15:00 -0800

Maybe you want to state that in the issue (i.e. #3353), as we've been discussing there about having this requirement?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#discussion_r368436587

---

From: Mike Bishop <[email-masked]>
Date: Mon, 20 Jan 2020 12:09:39 -0800

We do have this text in [5.1.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-consuming-and-retiring-conn):
> As discussed in Section 9.5, each connection ID MUST be used on packets sent from only one local address. An endpoint that migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address.

Is the missing piece that it should also be used for only one remote address, but this is the only scenario in which the server changes address?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#discussion_r368710424

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 20 Jan 2020 16:16:12 -0800

Yes. IIUC, the requirements are:
* A client MUST NOT reuse a CID across multiple paths (being identified by the 5 tuple).
* A server MUST NOT reuse a CID across multiple path, with the exception being that it MAY use a CID that has been used on one path on another path, if that new path is opened by a packet sent by a client using DCID for the old path.

We can combine these statements into one, and say that: An endpoint MUST NOT reuse a CID across multiple paths, with the exception being that it MAY use a CID that has been used on one path on another path, if that new path is opened by a packet sent by a client using DCID for the old path.

I think that is the most precise definition I can think of. If the above sounds fine, I can work on it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3354#discussion_r368764634