Re: [quicwg/base-drafts] Send complete SETTINGS (#2972)

[Mike Bishop <[e-mail]>]

@nharper:
> I'm a bit concerned that this says effectively says that it's optional (not RFC 2119 word) for clients to remember SETTINGS when sending early data, because now a server can't assume that a client is using the remembered SETTINGS in early data instead of the default settings.

That should be okay, because the defaults are intentionally the most restrictive settings possible.  If the client opts to retain/use a ticket for which it has no settings, then it doesn't get to use anything fancy until it sees the SETTINGS frame.

@kazuho:
> Specifically, the text does not update _when_ a SETTINGS frame is expected to be sent.
> 
> If we are to follow the design pattern of HTTP/2, I think that we should clarify that an endpoint MUST send a SETTINGS frame as soon as it becomes possible to send application data, even when the SETTINGS frame would be empty. Otherwise, we should clarify that a SETTINGS frame is to be sent only when one of the following conditions are met: a feature depending on non-default value of a settings parameter is to be used, or a frame other than a SETTINGS frame is to be transmitted on the control stream.

I think this is ultimately intractable.  You can't tell the difference between the control stream having a delay due to packet loss vs. the server simply not sending the settings until it has something else to send, or even not sending it at all.  If either party opts to run on pure defaults, we can't really stop them and getting an empty SETTINGS frame out of them doesn't really solve anything.

We shouldn't mandate a delay, which is how I read your second case.  We can lay down some encouragement to send it ASAP -- getting to use non-default settings in 0-RTT next time and being able to use any features of the control stream both push in that direction -- but failure to do so is probably not obvious and therefore a poor candidate for a MUST.

-- 
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/pull/2972#issuecomment-522732029