Subject: [quicwg/base-drafts] Remove SETTINGS_ACK, move application settings to the handshake (#181)

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Jan 2017 20:47:05 -0800

I know that this might be a hard decision to make, but we don't have many settings and it seems like we might be able to avoid changing them mid-connection.

Getting settings synchronization right is a pain and we really only have one that is ever likely to change and that's the header table size.  We don't allow initial flow control windows to change (no mechanism exists to allow it), so I question whether that needs changing.  If it does need to change, that would be for the same reason that the flow control window needs to change, which suggests we would need to devise a way to change those too.

SETTINGS_ACK is a huge amount of machinery.  With 0-RTT, it will mean that just opening a connection will trigger a flurry of SETTINGS_ACK frames from the client just to respond to the server's connection preface (assuming that we're still keeping that, it's not clear).  

On the other hand, if we reserved a space for application-specific traffic parameters (see #122), we could put the application-layer settings like header table size in the handshake.  That has some downsides (client values would be unencrypted and you would need to include one set of parameters per application protocol on offer), but it means that there couldn't ever be any confusion about the value of a given setting once the connection was open.

That would be a huge simplification to the HTTP mapping.

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

---

From: hardie <[email-masked]>
Date: Fri, 20 Jan 2017 08:43:47 -0800

On Thu, Jan 19, 2017 at 8:47 PM, Martin Thomson <[email-masked]>
wrote:

> On the other hand, if we reserved a space for application-specific traffic
> parameters (see #122 <https://github.com/quicwg/base-drafts/pull/122>),
> we could put the application-layer settings like header table size in the
> handshake. That has some downsides (client values would be unencrypted and
> you would need to include one set of parameters per application protocol on
> offer), but it means that there couldn't ever be any confusion about the
> value of a given setting once the connection was open.
>
It seems to have the consequence, though, that you must know which
applications are going to run at handshake time.  If I start with HTTP but
add DNS (not as DNS-over-HTTP, but as a DNS), then I must replace the
connection.

I'm also not thrilled with the client values being unencrypted here, isn't
there a  risk of fingerprinting as a result?

Ted

-- 
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/181#issuecomment-274119265

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jan 2017 16:37:03 -0800

I don't understand how you could possibly add another application protocol in the way you describe.

Yes, there is a fingerprinting risk, however for the settings that we have, the values are likely selected from a small fixed set of values.

-- 
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/181#issuecomment-274664631

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Jan 2017 23:00:18 -0800

Discussed in Tokyo; idea to constrain what the server can do to allow SETTINGS to be sent under crypto, with some signal back to the client (e.g., data, data on stream N) as ACK. PR needed. Comfort that they're immutable, as long as QPACK can handle this on its own.

-- 
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/181#issuecomment-274725323