Subject: [quicwg/base-drafts] clarify that an endpoint cannot block on SETTINGS (#2986)

From: Kazuho Oku <[email-masked]>
Date: Thu, 22 Aug 2019 18:18:12 -0700

A pull request against #2972, that tries to resolve the *original* issue raised in #2945.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * explain that and endpoint cannot expect the delivery of the peer's settings
  * "SHOULD NOT", with a less extreme example used as clarification

-- File Changes --

    M draft-ietf-quic-http.md (12)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2986.patch
https://github.com/quicwg/base-drafts/pull/2986.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/2986

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 22 Aug 2019 18:21:24 -0700

In response to https://github.com/quicwg/base-drafts/commit/5fadbbbff7a5e566a2c951376be7999aca2c7edb#r34801559 by @martinthomson:
> I don't get this latter part of the sentence. I think that we should mandate, with a "MUST", that endpoints not wait for a peer's SETTINGS frame before sending their own.

I am fine with using a keyword here. Though I'd argue that it does not need to be a MUST if an endpoint can assume that SETTINGS would arrive eventually (assuming that the endpoint would not send MAX_STREAMS or MAX_STREAM_DATA that might allow the peer to prioritize transmission of other streams).

Therefore I've gone with SHOULD NOT, using a less extreme example. To paraphrase, we are essentially forbidding an endpoint behave as described in https://github.com/quicwg/base-drafts/pull/2986/commits/dc7f6041fbae53e06e1875a1df561388e44156b2 (the example that you didn't get).

-- 
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/2986#issuecomment-524136029

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Aug 2019 19:22:22 -0700

martinthomson commented on this pull request.

I'm a little concerned about the standoff this permits, but otherwise, I think that this is a good change.

> @@ -2159,6 +2159,12 @@ the settings identifier space in HTTP/3 is substantially larger (62 bits versus
 16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. See
 {{iana-settings}}.
 
+An endpoint SHOULD NOT wait for the peer's settings to arrive before responding
+to other streams, as it cannot assume the peer's settings to arrive in a timely
+manner.  This is because the packet carrying the settings can be lost, or the

The problem here is that if both endpoints wait for settings from a peer, we have a situation where SETTINGS never gets sent.  If both peers decide to wait, then they wait forever.

Sorry, I wasn't clear that this was the concern in my other comment.

-- 
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/2986#pullrequestreview-278769930

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 22 Aug 2019 20:10:57 -0700

@kazuho pushed 1 commit.

4664b5c90834fce8e0affffcf66d697ddee2d3f7  MUST NOT wait for peer's SETTINGS before sending one's own

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2986/files/a907a06ba5e297b7a5baa524d77f3c48406d0349..4664b5c90834fce8e0affffcf66d697ddee2d3f7

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 22 Aug 2019 20:14:06 -0700

kazuho commented on this pull request.

Thank you for the clarification.

That's a good point, I agree that it's worth clarifying, so done in 4664b5c. I've added that to the main section, as that is the property that has *not* changed from HTTP/2.

-- 
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/2986#discussion_r316960820

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Aug 2019 20:16:00 -0700

martinthomson approved this pull request.

-- 
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/2986#pullrequestreview-278779433

---

From: Mike Bishop <[email-masked]>
Date: Fri, 23 Aug 2019 07:15:01 -0700

MikeBishop commented on this pull request.

> @@ -1330,11 +1330,13 @@ If an endpoint receives a SETTINGS frame on a different stream, the endpoint
 MUST respond with a connection error of type HTTP_WRONG_STREAM.
 
 SETTINGS parameters are not negotiated; they describe characteristics of the
-sending peer, which can be used by the receiving peer. However, a negotiation
-can be implied by the use of SETTINGS - each peer uses SETTINGS to advertise a
-set of supported values. The definition of the setting would describe how each
-peer combines the two sets to conclude which choice will be used.  SETTINGS does
-not provide a mechanism to identify when the choice takes effect.
+sending peer, which can be used by the receiving peer. An endpoint MUST NOT wait
+for the peer's SETTINGS frame to arrive before sending it's own SETTINGS frame.

This seems to duplicate the text at 1401-1403 (your version) / 1399-1401 (current PR).  Is there a reason it needs to be in two places, or was there a problem with the wording?

> @@ -2159,6 +2161,12 @@ the settings identifier space in HTTP/3 is substantially larger (62 bits versus

This appendix is informative; we shouldn't have 2119 requirements here.  (Besides, this is already covered by "Each endpoint MAY use these initial values to send messages before the peer's SETTINGS frame has arrived." on line 1396 / 1394.)  This is a difference from HTTP/2, so it's not unreasonable to mention here, though.

-- 
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/2986#pullrequestreview-279023516

---

From: ianswett <[email-masked]>
Date: Fri, 23 Aug 2019 08:17:49 -0700

ianswett commented on this pull request.

 SETTINGS parameters are not negotiated; they describe characteristics of the
-sending peer, which can be used by the receiving peer. However, a negotiation
-can be implied by the use of SETTINGS - each peer uses SETTINGS to advertise a
-set of supported values. The definition of the setting would describe how each
-peer combines the two sets to conclude which choice will be used.  SETTINGS does
-not provide a mechanism to identify when the choice takes effect.
+sending peer, which can be used by the receiving peer. An endpoint MUST NOT wait
+for the peer's SETTINGS frame to arrive before sending it's own SETTINGS frame.
+However, a negotiation can be implied by the use of SETTINGS - each peer uses
+SETTINGS to advertise a set of supported values. The definition of the setting
+would describe how each peer combines the two sets to conclude which choice will
+be used.  SETTINGS does not provide a mechanism to identify when the choice
+takes effect.

Adding a sub-section on negotiation may be worthwhile, but I think it's better under it's own paragraph and sub-section.  And maybe as part of the fix for #2985?

-- 
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/2986#pullrequestreview-279064717

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 26 Aug 2019 14:32:19 -0700

@kazuho pushed 2 commits.

fd556c0dc334cd92d9200a84c457a187d94f7053  Revert "MUST NOT wait for peer's SETTINGS before sending one's own", as it's stated elsewhere (pointed out by @MikeBishop)
d71650f5bef557df54e2eff2844b9c06dfc91671  MUST send SETTINGS, SHOULD NOT block, clarify why

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2986/files/4664b5c90834fce8e0affffcf66d697ddee2d3f7..d71650f5bef557df54e2eff2844b9c06dfc91671

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 26 Aug 2019 14:33:23 -0700

Thank you for pointing that out. I missed the existing text. Reverted in fd556c0.

-- 
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/2986#discussion_r317808484

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 26 Aug 2019 14:38:15 -0700

Yeah I now think that there is an issue in PR #2972.

It says that the sender SHOULD send SETTINGS, the receiver MAY use the initial value before receiving SETTINGS. We have a chance of deadlock by allowing the sender to not send SETTINGS, and the receiver to block on the receipt of SETTINGS.

d71650f resolves the deadlock by changing that to "MUST send SETTINGS". It also changes the recommendation on the receiver side to *not* block on SETTINGS as well as clarifying why. The normative text is moved into the main chapter, the appendix refers to 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/2986#discussion_r317810121

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 26 Aug 2019 14:40:55 -0700

@MikeBishop @ianswett Thank you for your comments.

As written in https://github.com/quicwg/base-drafts/pull/2986#discussion_r317810121, I think that there is still a potential deadlock in #2972 (which was the original issue in of #2945), and that this PR tries to fix that.

I am sorry for this being a separate PR against #2972, I had hoped that this would be more of a clarification that amends the PR, but it might have been wrong.

Anyways, I would appreciate it if you could see how this PR looks like now.

-- 
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/2986#issuecomment-525044302

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 27 Aug 2019 00:31:03 -0700

@kazuho pushed 1 commit.

29ce7d634cd16dbbaf9d9659c38b055f5448a38e  simplify to avoid endorsing such behavior

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2986/files/d71650f5bef557df54e2eff2844b9c06dfc91671..29ce7d634cd16dbbaf9d9659c38b055f5448a38e

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Aug 2019 00:40:07 -0700

-- 
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/2986#pullrequestreview-280007778

---

From: Mike Bishop <[email-masked]>
Date: Tue, 27 Aug 2019 11:38:12 -0700

Merged #2986 into http/complete-settings.

-- 
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/2986#event-2588088680