Subject: [quicwg/base-drafts] http3: Are reserved frames allowed before SETTINGS? (#2693)

From: Lucas Pardue <[email-masked]>
Date: Sun, 12 May 2019 11:46:00 -0700

We've had a long standing requirement that

> A SETTINGS frame MUST be sent as the first frame of each control
   stream (see Section 3.2.1) by each peer

By the way I interpret this, I put a check in my implementation that doesn't permit any frame until SETTINGS is received. Am I interpreting things correctly?

It would be more consistent to allow reserved frame types to appear at any point on any stream that carries frames. However, I'm fine with this requirement as is but it means there is a little more effort needed to handle reserved frame types across streams. 

-- 
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/issues/2693

---

From: Luca Niccolini <[email-masked]>
Date: Sun, 12 May 2019 12:00:45 -0700

In our implementation we are interpreting this in the same way: any frame on the control stream received before SETTINGS is a connection error. Even reserved frame types.

In general the way we handle this is by discarding frame types that are forbidden rather than checking frame types that are allowed on each stream. 

Here is a snippet from our code.
```
ParseResult HQControlCodec::checkFrameAllowed(FrameType type) {
  switch (type) {
    case hq::FrameType::DATA:
    case hq::FrameType::HEADERS:
    case hq::FrameType::PUSH_PROMISE:
      return HTTP3::ErrorCode::HTTP_WRONG_STREAM;
    default:
      break;
  }

  // SETTINGS MUST be the first frame on an HQ Control Stream
  if (!receivedSettings_ && type != hq::FrameType::SETTINGS) {
    return HTTP3::ErrorCode::HTTP_MISSING_SETTINGS;
  }
  // .. and a bunch of other checks here ..
```

In this way we avoid the extra effort needed to handle reserved frame types that you mentioned, if I am reading your statement correctly. 
Basically, some frame types are explicitly disallowed. All other frame types are equal, reserved or non-reserved. Do you foresee an extension possibly benefiting from sending a frame before settings ? 

-- 
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/issues/2693#issuecomment-491620307

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 12 May 2019 12:35:49 -0700

Thanks @lnicco you made me realise I asked the question wrong. 

This is about reserved *and* non-core frames. Section 7 says:

> Implementations MUST ignore unknown or unsupported values in all
   extensible protocol elements. Implementations MUST discard frames ...

I have no strong use case for delivering frames before SETTINGS. But I worry it falls into a slight grey area that might affect interop. I think the correct answer is that the control stream is special case and we should clarify that in Section 7.

-- 
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/issues/2693#issuecomment-491622774

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 12 May 2019 15:00:53 -0700

My preference goes to retaining the requirement as-is. This is the way H2 has worked, and I am not sure if there is a practical reason to change.

FWIW, we have a similar requirement for PRIORITY frame too, which I'm also fine with: _A PRIORITY frame received after other frames on a request stream MUST be treated as a connection error of type HTTP_UNEXPECTED_FRAME_ ([section 4.2.3](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#rfc.section.4.2.3)).

-- 
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/issues/2693#issuecomment-491633030

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 12 May 2019 15:32:10 -0700

Ooh yeah, that's a good catch too. 

We sort of have some text that captures this in section 4:

> Certain frames can only occur as the first frame of a particular stream type; these are indicated in Table 1 with a (1). Specific guidance is provided in the relevant section.

We could add tweaks or further guidance to this paragraph ( in a PR that also fixes #2692) that makes things explicitly 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/issues/2693#issuecomment-491634881

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 May 2019 11:01:08 -0700

On receipt, reserved is irrelevant -- it's just an unknown frame type.  The reservation is simply to permit senders to generate unknown frame types without accidental collision to a real extension the client might support.  So the question is whether "ignoring" unknown frame types means pretending that they weren't even there, and therefore the subsequent frame might still be the first frame on the stream.

I'm inclined to say no -- you take no action on a frame you don't recognize, but that doesn't mean that the next frame was the first frame.

-- 
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/issues/2693#issuecomment-491924995