RE: [HTTP/3]Sending reserved frame before SETTINGS

[Mike Bishop <[e-mail]>]

Yes, this text was added to record our decision when this question came up before.  An unknown frame is not SETTINGS.  If you define something new (EXTENDED_SETTINGS_REBORN), you can very well mandate that it be the next frame after SETTINGS, but it is not a SETTINGS frame and doesn’t satisfy the expectation to see a SETTINGS frame there.

From: QUIC <[e-mail]> On Behalf Of Lucas Pardue
Sent: Sunday, February 2, 2020 12:34 PM
To: Ian Swett <ianswett=[e-mail]>
Cc: IETF QUIC WG <[e-mail]>; Ryan Hamilton <[e-mail]>; Renjie Tang <renjietang=[e-mail]>
Subject: Re: [HTTP/3]Sending reserved frame before SETTINGS

I think the design of this is ok as is.

On Sat, 1 Feb 2020, 22:49 Ian Swett, <ianswett=[e-mail]<mailto:[e-mail]..org>> wrote:
Thanks for bringing this up Renjie.  I agree the subsequent text seems to clarify the answer.

However, is that the behavior we want, given it does limit extensibility in some small ways?

On Sat, Feb 1, 2020 at 11:25 AM Ryan Hamilton <[e-mail]<mailto:[e-mail]>> wrote:
Wow, interesting question!

6.2.1 requires the SETTINGS frame to be first on the control frame:


   If the first frame of the control stream is any other frame

   type, this MUST be treated as a connection error of type

   H3_MISSING_SETTINGS.

Whereas 7.2.9 says reserved frames have no semantic meaning:


   Frame types of the format "0x1f * N + 0x21" for integer values of N

   are reserved to exercise the requirement that unknown types be

   ignored (Section 9<https://tools.ietf.org/html/draft-ietf-quic-http-25#section-9>).  These frames have no semantics, and can be sent

   on any open stream when application-layer padding is desired.


This sounds like a conflict since something that has no semantics seems like it should not cause errors! However, looking Section 9 I think we find the resolution:

   Implementations MUST ignore unknown or unsupported values in all

   extensible protocol elements.  Implementations MUST discard frames

   and unidirectional streams that have unknown or unsupported types.

   This means that any of these extension points can be safely used by

   extensions without prior arrangement or negotiation.  However, where

   a known frame type is required to be in a specific location, such as

   the SETTINGS frame as the first frame of the control stream (see

   Section 6.2.1<https://tools.ietf.org/html/draft-ietf-quic-http-25#section-6....2.1>), an unknown frame type does not satisfy that

   requirement and SHOULD be treated as an error.



So it seems that it's illegal to send a GREASED frame before the SETTINGS frame. Does that sound right to you?



Cheers,



Ryan

On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang <renjietang=[e-mail]<mailto:[e-mail]>> wrote:
Hi all,

When I was implementing greasing for HTTP/3 frames, I came across a potential confusion.

Presumably, if a non-reserved unknown frame is received before SETTINGS on a control stream, the connection should be closed.

But if a reserved frame is received before SETTINGS frame on a control stream, does it count as an error and close the connection? Or should it simply be ignored because it has no semantic meaning?

Thanks!
Renjie