Subject: Re: [HTTP/3]Sending reserved frame before SETTINGS

From: Ryan Hamilton <[email-masked]>
Date: Sat, 1 Feb 2020 08:15:04 -0800

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=
[email-masked]> 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
>

---

From: Ian Swett <[email-masked]>
Date: Sat, 1 Feb 2020 17:48:48 -0500

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 <[email-masked]> wrote:

>    ignored (Section 9 <https://tools.ietf.org/html/draft-ietf-quic-http-25#section-9>).  These frames have no semantics, and can be sent
>    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
> So it seems that it's illegal to send a GREASED frame before the SETTINGS frame. Does that sound right to you?
>
>
> Cheers,
>
>
> Ryan
>
>
>> Presumably, if a non-reserved unknown frame is received before SETTINGS
>> on a control stream, the connection should be closed.
>>

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 2 Feb 2020 11:34:27 +0000

I think the design of this is ok as is.

On Sat, 1 Feb 2020, 22:49 Ian Swett, <ianswett=[email-masked]>
wrote:

> However, is that the behavior we want, given it does limit extensibility
> in some small ways?
>
>>    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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 4 Feb 2020 09:44:44 +0000

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

On Sat, 1 Feb 2020, 22:49 Ian Swett, <ianswett=[email-masked]<mailto:[email-masked]..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 <[email-masked]<mailto:[email-masked]>> wrote:
Wow, interesting question!

   H3_MISSING_SETTINGS.

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

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:

   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

Cheers,

Ryan

On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang <renjietang=[email-masked]<mailto:[email-masked]>> 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

---

From: Ian Swett <[email-masked]>
Date: Tue, 4 Feb 2020 06:11:49 -0500

Thinking more, I don't think we're losing much with this restriction, so
I'm fine with it as is.

On Tue, Feb 4, 2020 at 4:44 AM Mike Bishop <[email-masked]> wrote:

> 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 <[email-masked]> *On Behalf Of * Lucas Pardue
> *Sent:* Sunday, February 2, 2020 12:34 PM
> *To:* Ian Swett <ianswett=[email-masked]>
> *Cc:* IETF QUIC WG <[email-masked]>; Ryan Hamilton <[email-masked]>;
> Renjie Tang <renjietang=[email-masked]>
> *Subject:* Re: [HTTP/3]Sending reserved frame before SETTINGS
>
>
>
> On Sat, 1 Feb 2020, 22:49 Ian Swett, <ianswett=[email-masked]
> <[email-masked]..org>> wrote:
>
>    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
>