Subject: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)

From: Kazuho Oku <[email-masked]>
Date: Wed, 31 Jul 2019 19:01:09 -0700

It seems that there are disagreement among the implementors, regarding when the SETTINGS frame need to be sent.

Some argue that it needs to be sent right after the handshake, even if the SETTINGS frame would contain no parameters. Some argue that it can be delayed, until the need to send something on the control stream arises.

I think we should clarify the expected behavior.

FWIW, existing text that refers to the topic are:
[section 3.3](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#rfc.section.3.3):
> After the QUIC connection is established, a SETTINGS frame (Section 7.2.5) MUST be sent by each endpoint as the initial frame of their respective HTTP control stream (see Section 6.2.1)

[section 6.2.1](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#rfc.section.6.2.1):
> Each side MUST initiate a single control stream at the beginning of the connection and send its SETTINGS frame as the first frame on this stream.

[section 7.2.5](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#rfc.section.7.2.5):
> SETTINGS frames always apply to a connection, never a single stream. A SETTINGS frame MUST be sent as the first frame of each control stream (see Section 6.2.1) by each peer, and MUST NOT be sent subsequently.

cc @DavidSchinazi @LPardue @rmarx 

-- 
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/2945

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 31 Jul 2019 19:06:10 -0700

My two cents go to requiring the frame to be sent immediately after the handshake. IIRC, we discussed the issue long ago, and IIRC the consensus was that clients "can" wait for the server's SETTINGS frame before sending requests. Doing so improves the efficiency of QPACK for example, assuming that the server supports the use of dynamic table.

Generally speaking, I think it is preferable to be able to learn about the capabilities of the peer at the earliest moment. OTOH, I do not think there is a compelling reason to postpone sending SETTINGS 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/2945#issuecomment-517088885

---

From: Luca Niccolini <[email-masked]>
Date: Wed, 31 Jul 2019 20:48:12 -0700

I agree with you and I vote for sending SETTINGS as soon as possible right after handshake. 

I want to warn you though that this does not prevent an implementor to chose something different since for how the protocol is designed -- after we removed waiting for receiving SETTINGS to send a request -- everything will keep working. As you said it would just be in a non-optimal state: i.e. without the ability to use the QPACK dynamic table and without GOAWAY. 

This is in fact something we never thoroughly test at interop since we only send a single request on a single stream and stop there.

As a sad/clowny story, we had a bug once where both endpoints would fail at reading from all unidirectional streams. It was so subtle that everything keep working fine, just no compression and no graceful shutdown.

-- 
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/2945#issuecomment-517107263