Subject: [quicwg/base-drafts] Crisp definition of BLOCKING and friends (#1889)

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Oct 2018 04:30:45 +0000 (UTC)

Recent discussion around the use of BLOCKING frames highlighted some
inconsistency - and even disagreement - about what the purpose of the
frames are.  If you read through all the text for the flow
control-related frames, it is clear that the frame carries the *limit*
at the time the frame is sent.

> These frames always include the limit that is causing blocking at the
> time that they are transmitted.

This enacts that change more consistently, especially for
STREAM_ID_BLOCKED, which was the most unclear.

The discussion on #1851 suggested that there was value in knowing what
the sender (or stream opener) wanted to get to.  That is, the frames
would carry a higher value.  If the limit was X and the sender wanted to
send octet X+Y (or open stream X+Y), they would convey that information
instead.  The theory here is that the larger value (X+Y) would be sent,
allowing the receiver to make those resources available.

The problem with this alternative approach is that the value advertised
changes over time and it is difficult to connect the signal (a BLOCKED
frame), with the limit that was in force at the time.

I suspect that there is value in signaling the desired limits as well,
but that would require greater justification.  It also entails a change
and I'm leery of feature creep at this stage.

Closes #1851, #1850.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Crisp definition of BLOCKING and friends

-- File Changes --

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

-- Patch Links --

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 18 Oct 2018 21:46:18 -0700

kazuho commented on this pull request.

> @@ -4340,8 +4340,9 @@ The STREAM_ID_BLOCKED frame contains a single field.
 
 Stream ID:
 
-: A variable-length integer indicating the highest stream ID that the sender
-  was permitted to open.
+: A variable-length integer indicating the stream ID limit at the time the
+  sender was unable to open new streams.

Same issue here.

I am afraid that the text might still imply the same thing; i.e. the maximum stream ID that the sender was permitted to open at the time the sender was unable to open the streams.

> @@ -4281,8 +4281,8 @@ The BLOCKED frame contains a single field.
 
 Offset:
 
-: A variable-length integer indicating the connection-level offset at which
-  the blocking occurred.
+: A variable-length integer indicating the connection flow control limit at the
+  time the frame is sent.

I actually prefer the old text, assuming that we do not have a clarification on what "limit" means here. In other parts of the transport protocol we represent the limit using an "inclusive maximum." But here, we need a limit expressed as "exclusive maxmimum."

IMO the original text is clearer in stating that the offset is "maximum offset permitted by MAX_DATA + 1", by saying that the transmitted value is "the offset at which the blocking occurred."

-- 
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/1889#pullrequestreview-166377837

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Oct 2018 22:22:14 -0700

martinthomson commented on this pull request.

 Stream ID:

You are right, this fails to address the original issue.  I will amend the definition of MAX_STREAM_ID to address that concern then - and use your "exclusive maximum" approach.

-- 
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/1889#discussion_r226536452

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Oct 2018 22:31:37 -0700

Stream ID:

Hmm, that's a tricky one, changing the definition of MAX_STREAM isn't that easy.

With stream IDs, if I receive MAX_STREAM_ID of `N`, then the test for whether something is allowed is `id <= N`.  With stream octets, the test is `offset < MAX_STREAM_DATA`.  That makes this harder.

So with the latter, saying that you can't send `offset` is clean and simple (wording notwithstanding).  With streams though, you would be saying "I can only send `N` (but want to send `N+4`)", which is awkward, I agree.

Is changing the definition of MAX_STREAM_ID worth 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/1889#discussion_r226537264

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 19 Oct 2018 00:52:33 -0700

Stream ID:

That sounds like an excellent observation.

I think I'd agree to changing the definition of MAX_STREAM_ID to send the number of streams rather than the stream ID. We might also want to rename the frame to MAX_STREAM_COUNT.

There are certain aspects that are not elegant in the way MAX_STREAM_ID is defined now:
* we have two maximums; one for unidirectional streams
* we exchange counts using TP but we transmit maximum in the frame

These issues will be resolved by sending the counts.

-- 
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/1889#discussion_r226560151

---

From: Nick Banks <[email-masked]>
Date: Fri, 19 Oct 2018 06:50:12 -0700

nibanks commented on this pull request.

 Stream ID:

If we changed it to MAX_STREAM_COUNT, we'd have to use one additional bit from the type to indicate unidirectional/bidirectional, right? To me, my favorite thing (if we made that change) would be that I no longer have to validate if the peer is trying to set my limit on them (i.e. ownership bit).

-- 
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/1889#discussion_r226653712

---

From: Marten Seemann <[email-masked]>
Date: Fri, 19 Oct 2018 15:05:24 -0700

marten-seemann commented on this pull request.

 Stream ID:

Assuming that MAX_STREAM_COUNT is supposed to encode the number of streams *since the beginning of the connection* (and not the concurrently open streams, as we had in some earlier version of the draft), I think this would be a good change to make, since we'd use the same encoding for the transport parameters and the frame.
Not sure if MAX_STREAM_COUNT is the best name for this, maybe we can go with something analogous to the transport parameters (initial_max_{uni,bidi}_streams), and name it MAX_STREAMS frame?

-- 
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/1889#discussion_r226793378

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 15:56:11 -0700

Closing in favour of a bigger change.

-- 
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/1889#issuecomment-432450785

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 15:56:13 -0700

Closed #1889.

-- 
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/1889#event-1921948749