[quicwg/base-drafts] 005ac3: Crisp definition of BLOCKING and friends

[Martin Thomson <[e-mail]>]

  Branch: refs/heads/define-blocking-values
  Home:   https://github.com/quicwg/base-drafts
  Commit: 005ac34fbfb23d47bab46ae8c897a0429284f778
      https://github.com/quicwg/base-drafts/commit/005ac34fbfb23d47bab46ae8c897a0429284f778
  Author: Martin Thomson <[e-mail]>
  Date:   2018-10-19 (Fri, 19 Oct 2018)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Crisp definition of BLOCKING and friends

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.



      **NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.