Subject: [quicwg/base-drafts] Static table negotiation (#1343)

From: Mike Bishop <[email-masked]>
Date: Wed, 09 May 2018 12:51:43 -0700

During the discussion on #904, it was proposed that a means of using different static tables might be worthwhile.  We've already found that the web has moved on a bit from the headers in RFC 7541, and the same is likely to be true of whatever we put in HQ1.  It might be nice not to need a protocol rev to update the table every few years.

Another reason to support multiple tables:  Both the HPACK and the draft QPACK static table are based on browser web traffic.  Browsers and web aren't the whole of HTTP usage, and other users of HTTP might well define a static table better suited to their needs.  If such a mechanism is available, it might also make sense to define separate client and server tables.

A few models have been suggested, none of them ideal:

1. **An instruction to switch to a new static table.**  Probably difficult to actually work out, because of reordering of request streams with the control stream, but has the advantage that you can start by assuming the default table and switch to another later if the peer supports it.
2. **Crossed SETTINGS values.**  Each side declares its supported tables in preferred order.  Each side encodes using its most preferred table that was also in the peer's list; decode using the first entry in the peer's list that was also in your list.  Requires consuming the server's SETTINGS frame before sending any requests, which clients don't currently have to do, but the requirement to remember settings for 0-RTT plus the server's ability to send in 0.5-RTT makes this less onerous than it would have been in H2.  (Note that this option could also be implemented as an HTTP/2 extension.)
3. **Crossed transport parameter.**  As previous, but carried in a transport parameter.  There are currently no application-level settings exchanged in transport parameters, both due to separation of concerns and because the transport doesn't know in its initial flight what application protocol will be selected (in the general case), so it would need to carry the settings of all application protocols that ALPN is proposing.

I feel like this is interesting, but I'm undecided about whether it's unnecessary feature creep or useful future-proofing.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 May 2018 14:57:46 -0700

The simplest answer - don't - seems best to me.  The HPACK table is poor, and was poor the day it was released, but that doesn't mean it is useless.  The same is likely to apply to QPACK also.  I think that updating the table based on what we know today is a good move, but a fixed table is OK.

If it were easy to do, then I'd be far more likely to be interested, but as you say it's pretty hard.  The best design is probably to preface every HEADERS frame with a table identifier.  That's close to the instruction idea, but recognizes that every HEADERS frame uses the static table and that synchronization is hard.  That leads me to question whether the extra byte on every frame could be regained by having a better table.  (Yes, the instruction could be dropped once you reached a steady state, but that's both hard to manage; besides, compression efficiency during those first round trips matters most.) 

-- 
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/1343#issuecomment-387888124

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 09 May 2018 15:12:58 -0700

I've said it elsewhere but will will do so again, I like the broad concept for the reasons you put so well. I don't like option 3 because it breaks layering.

It might be worth clarifying if proposed models require modification to the QPACK behavioural / algorithmic side, or if this is purely a data structure form of change (that needs bootstrapping support independent of QPACK). Having an answer to that might help settle fears that QPACK is unstable.

If this is just data structures + bootstrap, I think this might be merit in running this as an experiment for possible inclusion at a later stage, without being critical to the delivery of HTTP/QUIC. 

So while we are here, the other model I've considered is: 

Alt-Svc advertisement of static table(s). E.g. a base64 encoded representation of the table(s) that MAY be used to communicate with the alternative. When a client connects to the alternative this is validated (somehow, maybe option 2). This could support split tables, with the server mandating what tables it is expecting the client to use, this maybe addresses client waiting for SETTINGS. Clients don't attempt to connect to alternatives that are advertised tables they are unhappy with.

-- 
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/1343#issuecomment-387891410

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 10 May 2018 03:37:49 -0700

I think the Alt-Svc advertisement proposed by @LPardue is a good idea.  The client can just use the static QPACK table that it knows the server supports.

-- 
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/1343#issuecomment-388018039

---

From: Mike Bishop <[email-masked]>
Date: Thu, 10 May 2018 09:35:48 -0700

Actually, while this may turn into a separate issue, I just saw that the HQ draft *already* contains this restriction, added by #1207:

> When a 1-RTT QUIC connection is being used, the client MUST NOT send requests prior to receiving and processing the server’s SETTINGS frame.

So that's already there, and if we find it objectionable, we should open an issue to discuss taking it out again.

The Alt-Svc thing is an interesting option.  It differs from our current advertisement of QUIC version, which is only a hint and a performance optimization.  If that's wrong, oh well, you negotiate.  This would be considered actual "hard" knowledge about the server used when encoding packets, and it's harder to recover from.

-- 
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/1343#issuecomment-388109352

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 10 May 2018 21:19:27 -0700

To expand on Mike's comment after thinking further, the quirk of Alt-Svc also becomes that it effectively defines a host-level static table rather than a connection-one. This introduces some weird (although perhaps not undesirable) synergies between QUIC session resumption and Alt-Svc freshness i.e a client that accepts an alternative as valid could continue to use it's static table across different QUIC connections to the same host.

Thinking about the negotiation more generally. The proposals are connection-level. There is potential merit in an ability for different API endpoints to have different table contexts, however differentiating endpoints by URL path is not presently possible. And to take this concept further, you could imagine some benefit (in a multipath world) of different paths having different table contexts. However, this could all be TFH, with questionable real world benefit.

-- 
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/1343#issuecomment-388255397

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 10 May 2018 21:46:20 -0700

I agree with @martinthomson that we don't need to design negotiation now. I also share @MikeBishop's concern that it is hard to "negotiate" the static table using Alt-Svc. I do not think it would work well, for example when the server gets replaced to a different software before the client reconnects.

-- 
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/1343#issuecomment-388258464