Subject: [quicwg/base-drafts] Allow both error types for >2^60 in MAX_STREAMS (#3792)

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Jun 2020 00:11:51 -0700

STREAM_LIMIT_ERROR is fine.
FRAME_ENCODING_ERROR is fine.

We just need to be consistent in mentioning both throughout.

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

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

-- Commit Summary --

  * Allow both error types for &gt;2^60 in MAX_STREAMS

-- File Changes --

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

-- Patch Links --

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

---

From: Marten Seemann <[email-masked]>
Date: Fri, 26 Jun 2020 00:16:09 -0700

I'd prefer to not make this change. STREAM_LIMIT_ERRORs only occur when the peers tries to open a stream with a too high stream ID, not when the peer is granting you a higher stream budget.
As this stream ID doesn't even exist, this is clearly a FRAME_ENCODING_ERROR.

-- 
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/3792#issuecomment-650019583

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Jun 2020 00:35:11 -0700

That's a reasonable position.  That says that STREAM_LIMIT_ERROR is only for violations of a limit, not for mistakes in setting it.  That keeps the blame firmly on one side of the fence.

I saw the opposite angle too: the frame type in CONNECTION_CLOSE does provide a way to disambiguate source.  STREAM_LIMIT_ERROR+MAX_STREAMS is fairly clear.

-- 
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/3792#issuecomment-650028535