Subject: [quicwg/base-drafts] Talk about concurrency in H3 vs. H2 (#3114)

From: Mike Bishop <[email-masked]>
Date: Thu, 17 Oct 2019 18:01:28 +0000 (UTC)

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

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

-- Commit Summary --

  * Talk about concurrency

-- File Changes --

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

-- Patch Links --

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

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 17 Oct 2019 11:24:23 -0700

LPardue commented on this pull request.

> +QUIC manages stream concurrency on behalf of HTTP/3.  QUIC considers a stream
+closed when all sent data and all acknowledgements for received data have been
+acknowledged by the peer.  HTTP/2 considers a stream closed when the frame
+containing the END_STREAM bit has been committed to the transport. As a result,
+the stream for an equivalent exchange will remain "active" for at least one
+additional round trip.  Implementations of HTTP/3 might choose to permit a
+larger number of concurrent streams than in HTTP/2 to achieve equivalent
+concurrency, depending on the expected usage patterns.

This looks good but if you're gonna pop the bonnet to fix something, I think we probably want to talk about the concurrency of request and push streams separately.  

The text here is more focused on describing the behaviour of request streams. So I would be more specific and say that a HTTP/3 server might choose to permit a larger number of concurrent client-initiated bidirectional streams. 

Then I would discuss considerations for push concurrency, highlighting the additional controls in the shape of push ID but identifying that push stream concurrency is competing against other unidirectional stream type (core or extensions) for the server-initiated unidirectional stream space.

-- 
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/3114#pullrequestreview-303456374

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 17 Oct 2019 11:36:15 -0700

kazuho commented on this pull request.

> @@ -1814,6 +1814,15 @@ considerations about exhaustion of stream identifier space apply, though the
 space is significantly larger such that it is likely that other limits in QUIC
 are reached first, such as the limit on the connection flow control window.

I feel this "on behalf of HTTP/3" a bit confusing, because my mental model is that it is generally a responsibility of the transport to manage streams, and that HTTP/2 was the exception.

Maybe something like "In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC."

> @@ -1814,6 +1814,15 @@ considerations about exhaustion of stream identifier space apply, though the
 space is significantly larger such that it is likely that other limits in QUIC
 are reached first, such as the limit on the connection flow control window.

I think this sentence is incorrect.

I think it should be: "QUIC considers a stream closed when all data have been received and all the sent data have been acknowledged."

> @@ -1814,6 +1814,15 @@ considerations about exhaustion of stream identifier space apply, though the
 space is significantly larger such that it is likely that other limits in QUIC
 are reached first, such as the limit on the connection flow control window.

How about "will typically remain "active" for one additional roundtrip"?

The lifetime of a stream would be indifferent from HTTP/2 in the pathological case where the request-side of the stream is closed after the response-side is being closed.

-- 
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/3114#pullrequestreview-303461344

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Oct 2019 11:35:46 -0700

@MikeBishop pushed 2 commits.

8ceca2ad00e27395b664a678116769841499db65  Talk about push separately
ad5ed87ca8f7ea3a5116efd9b2e820fe6ade6dc7  Precision, thanks to @kazuho

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3114/files/1705a1589d16b12c894852e41cd1431a70d4d33e..ad5ed87ca8f7ea3a5116efd9b2e820fe6ade6dc7

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 18 Oct 2019 11:41:02 -0700

> @@ -1814,6 +1814,22 @@ considerations about exhaustion of stream identifier space apply, though the
 
+In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC.  QUIC
+considers a stream closed when all data has been received and sent data has been
+acknowledged by the peer.  HTTP/2 considers a stream closed when the frame
+containing the END_STREAM bit has been committed to the transport. As a result,
+the stream for an equivalent exchange will typically remain "active" for one
+additional round trip.  HTTP/3 servers might choose to permit a larger number of
+concurrent client-initiated bidirectional streams to achieve equivalent
+concurrency than were permitted in HTTP/2, depending on the expected usage
+patterns.
+
+Due to the presence of other unidirectional stream types, HTTP/3 does not rely
+exclusively on the number of concurrent unidirectional streams to control the
+number of concurrent pushes received by a client.  Instead, HTTP/3 clients use

```suggestion
number of concurrent in-flight pushes.  Instead, HTTP/3 clients use
```

Avoid the rabbit whole of received by client or sent by server.

-- 
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/3114#pullrequestreview-304071242

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Oct 2019 14:52:17 -0700

@MikeBishop pushed 1 commit.

8645d19b2903e701a14fe06172281578bbb73d70  Update draft-ietf-quic-http.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3114/files/ad5ed87ca8f7ea3a5116efd9b2e820fe6ade6dc7..8645d19b2903e701a14fe06172281578bbb73d70

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Oct 2019 14:53:45 -0700

ca1c4940f6f6f8cf081ecbbef9d2a2e08872522d  Update draft-ietf-quic-http.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3114/files/254f7728a6552c61ea8230c59d5291802267ff3b..ca1c4940f6f6f8cf081ecbbef9d2a2e08872522d

---

From: afrind <[email-masked]>
Date: Mon, 21 Oct 2019 09:06:05 -0700

afrind commented on this pull request.

"permit a larger number...than were permitted" makes sense, but there are so many words between them that it's kind of hard to parse.

-- 
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/3114#pullrequestreview-304676576

---

From: ianswett <[email-masked]>
Date: Mon, 21 Oct 2019 09:41:58 -0700

ianswett commented on this pull request.

Or a reset has been sent and acknowledged.

-- 
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/3114#discussion_r337122134

---

From: ianswett <[email-masked]>
Date: Mon, 21 Oct 2019 10:30:13 -0700

```suggestion
concurrency to in HTTP/2, depending on the expected usage
```

-- 
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/3114#pullrequestreview-304726775

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2019 19:03:27 -0700

martinthomson requested changes on this pull request.

I think that this isn't quite right.  It makes an unstated assumption, namely that the transport maintains a fixed "active stream count" that it uses to increment the maximum stream ID.  The decision to increase the maximum stream identifier could be made at the same point in HTTP/3 as it is in HTTP/2 if the transport+HTTP stacks were to decide that.

I think that we can stop by saying that the state machine is different and that this might result in HTTP/3 streams being regarded as closed later than in HTTP/2.  This could reduce the effective stream concurrency if the number of streams is used in a similar way to decide the maximum stream ID.

-- 
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/3114#pullrequestreview-304936676

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Oct 2019 15:58:12 -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/3114#pullrequestreview-308883431

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 Oct 2019 15:58:21 -0700

Merged #3114 into master.

-- 
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/3114#event-2754089298