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

[Martin Thomson <[e-mail]>]

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