Minor inconsistency of error when MAX_STREAMS exceeds 2^60

[LPardue]

Over on cloudflare/quiche#565 we had a discussion about whether a MAX_STREAMS frame with value exceeding 2^60 generates a FRAME_ENCODING or a STREAM_LIMIT error.

Draft 29 Section 19.11 says:

Maximum Streams: A count of the cumulative number of streams of the
corresponding type that can be opened over the lifetime of the
connection. This value cannot exceed 2^60, as it is not possible
to encode stream IDs larger than 2^62-1. Receipt of a frame that
permits opening of a stream larger than this limit MUST be treated
as a FRAME_ENCODING_ERROR.

but as @goelvidhi points out, Section 4.5 says

If a max_streams transport parameter or MAX_STREAMS frame is received
with a value greater than 2^60, this would allow a maximum stream ID
that cannot be expressed as a variable-length integer; see
Section 16. If either is received, the connection MUST be closed
immediately with a connection error of type STREAM_LIMIT_ERROR

Meanwhile, for the STREAMS_BLOCKED frame in Section 19.15 we have:

Receipt of a frame that encodes a larger stream ID MUST be treated as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR.

I suspect both Vidhi and I are correct, bogus MAX_STREAMS can be treated as either STREAM_LIMIT or FRAME_ENCODING. If so, its probably a minor editorial fix to state either/or in both the sections.

[ianswett]

@marten-seemann suggested that it should only be a FRAME_ENCODING_ERROR, as it's invalid to send a MAX_STREAMS larger than 2^60 under any circumstance, regardless of connection state, and I agree that's the clearest application of our principles.

[kazuho]

I agree that requiring the use of FRAME_ENOCDING_ERROR is fine.

Even though we occasionally allow an endpoint to use multiple error codes when there is more than one way of checking the status (i.e. FLOW_CONTROL_ERROR vs. FRAME_ENCODING_ERROR for STREAM frames), the check required in this particular case is purely unrelated to the connection state. Hence my +1.

[LPardue]

I would be happy with a single error too. I'm not fussy about the actual code used as long as the spec is clear and consistent. That means that we'd need to reduce STREAMS_BLOCKED to one error code too, and potentially any other situation that allows either.

[martinthomson]

I'm going to drop #3792. I agree with the comments suggesting that FRAME_ENCODING_ERROR is the right answer.

Note that you might still receive a different error, as we permit endpoints that detect multiple errors to send any that it detects, and this case clearly justifies use of STREAM_LIMIT_ERROR.