Subject: [quicwg/base-drafts] 2bff0a: An endpoint cannot renege on advertised limits

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jul 2018 17:50:56 -0700

Branch: refs/heads/cant-renege
  Home:   https://github.com/quicwg/base-drafts
  Commit: 2bff0a9c4b2dc99c94242c1f38b157c63a31fbc5
      https://github.com/quicwg/base-drafts/commit/2bff0a9c4b2dc99c94242c1f38b157c63a31fbc5
  Author: Martin Thomson <[email-masked]>
  Date:   2018-08-01 (Wed, 01 Aug 2018)

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

  Log Message:
  -----------
  An endpoint cannot renege on advertised limits

For MAX_DATA, MAX_STREAM_DATA, and MAX_STREAM_ID equally, having a MUST
NOT on reneging isn't aligned with practice.  Some implementations
retransmit frame contents without updating the contents of these frames
and that isn't strictly a problem.

Some would have like to police this, but we seem to have consensus to
disallow that.  It creates a coupling between frame processing and
packet numbers that we don't currently have, and it seems that we don't
really want to have either.  More to the point, it prevents the sorts of
optimizations that some people really want.

So, rather than use a MUST NOT renege, observe that it is really just a
an axiom that arises as a consequence of how processing these frames
works: if the value is reduced, then ignore the value.  Whether that is
as a result of out of order arrival, or an optimization, that's OK.

Closes #1612, #447 (the latter for real this time).

      **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.