![](\"/user_uploads/2/19/wGa_OUWBEUdPIhLLDOE_Pjzo/IMG_20231109_150100.jpg\")
Hi all!
", "time": "2023-11-09T14:01:17Z"}, {"author": "Francesca Palombini", "text": "note well: https://www.ietf.org/about/note-well/
", "time": "2023-11-09T14:02:02Z"}, {"author": "Mike Bishop", "text": "match-search isn't great; the URI component is called \"query\", so let's use that.
", "time": "2023-11-09T14:08:52Z"}, {"author": "Spencer Dawkins", "text": "It makes me happy that I can hear a dog barking during an IETF meeting. My wife would be even happier ...
", "time": "2023-11-09T14:10:18Z"}, {"author": "David Schinazi", "text": "Has Patrick's dog read the note well?
", "time": "2023-11-09T14:10:55Z"}, {"author": "Samuel Weiler", "text": "It's far better than having the participants in the room barking, which I've seen before.
", "time": "2023-11-09T14:10:58Z"}, {"author": "Erik Nygren", "text": "The transcription appears to be encoding barks as \"Whoa\" which amuses me.
", "time": "2023-11-09T14:11:43Z"}, {"author": "Timothy Terriberry", "text": "Sorry, seem to have trouble unmuting the mic.
", "time": "2023-11-09T14:11:58Z"}, {"author": "David Schinazi", "text": "Press the icon that looks like a microphone that's greyed out
", "time": "2023-11-09T14:12:21Z"}, {"author": "Timothy Terriberry", "text": "Right, I pressed it, and it didn't do anything.
", "time": "2023-11-09T14:12:37Z"}, {"author": "Timothy Terriberry", "text": "It worked in an earlier session. Not sure what changed.
", "time": "2023-11-09T14:12:46Z"}, {"author": "David Schinazi", "text": "Maybe type your message here and we can relay it at the mic
", "time": "2023-11-09T14:12:51Z"}, {"author": "Timothy Terriberry", "text": "I had two questions: (1) I don't see a lot of details in the draft about how the dictionary is used by the different algorithms. Maybe this is \"obvious\" but it might be helpful to at least have reference(s).
", "time": "2023-11-09T14:14:18Z"}, {"author": "David Schinazi", "text": "ok I've gotten in queue, I'll ask them for you
", "time": "2023-11-09T14:14:33Z"}, {"author": "Timothy Terriberry", "text": "(2) The motivation for that question is that one of the things I found very helpful for SDP compression with gzip (for WebRTC) was to truncate the original message at some cutoff shorter than the maximum window size. Making sure the start of the document is inside the window helps avoid re-sending some headers that only appear once, and leaving a little bit of extra room makes sending the same SDP with only minor changes work much better. Have you considered being able to specify a limit on the amount of the document used for the dictionary?
", "time": "2023-11-09T14:17:37Z"}, {"author": "Julian Reschke", "text": "(somebody's mic is making noises)
", "time": "2023-11-09T14:21:01Z"}, {"author": "Kazuho Oku", "text": "If we have Etag, we'd be inclined to skip comparing SHA256...
", "time": "2023-11-09T14:22:40Z"}, {"author": "Mike Bishop", "text": "\"The dictionary is passed as foo to the process in Section 5.3.1 of [BLAH]....\"
For gzip, you are limited to a bit less than 32 kB as a dictionary.
", "time": "2023-11-09T14:24:45Z"}, {"author": "Spencer Dawkins", "text": "Erik Nygren said:
\n\n\nThe transcription appears to be encoding barks as \"Whoa\" which amuses me.
\n
We did have a newcomer ask \"where are the hums I was told about?\" yesterday. Maybe this is an opportunity to add \"hum for Yes, woof for no\" to IETF culture ... :sunglasses:
", "time": "2023-11-09T14:24:47Z"}, {"author": "Timothy Terriberry", "text": "If you specify the whole response, you will just get the last ~32 kB.
", "time": "2023-11-09T14:25:07Z"}, {"author": "Kazuho Oku", "text": "Using first 32KB is more than sufficient I believe for the traditional compression methods
", "time": "2023-11-09T14:25:07Z"}, {"author": "Timothy Terriberry", "text": "What I am saying is that being able to specify a limit means you can get the _first_ ~32 kB.
", "time": "2023-11-09T14:25:57Z"}, {"author": "David Schinazi", "text": "_Tommy Policy has entered the room_
", "time": "2023-11-09T14:26:06Z"}, {"author": "Rory Hewitt", "text": "Shhhh
", "time": "2023-11-09T14:27:47Z"}, {"author": "Timothy Terriberry", "text": "And you actually want slightly less than the maximum.
", "time": "2023-11-09T14:27:49Z"}, {"author": "Mike Bishop", "text": "\nImagine you send a document with one character inserted.
", "time": "2023-11-09T14:28:15Z"}, {"author": "Alex Chernyakhovsky", "text": "I thought we just _had_ cookies [at the snack break]
", "time": "2023-11-09T14:28:46Z"}, {"author": "Timothy Terriberry", "text": "If your dictionary is the maximum window size, after sending that one inserted character, for every byte after that it will expire from the window right before you wanted to use it.
", "time": "2023-11-09T14:29:06Z"}, {"author": "Kazuho Oku", "text": "Yeah first few kilos will be more than enough to capture common pattern found in JavaScript or CSS or whatever
", "time": "2023-11-09T14:29:10Z"}, {"author": "Patrick Meenan", "text": "At least for now, gzip dictionary support isn't a target for the compression dictionary support. It certainly could be but it sounds like it would be pretty limited relative to the use cases that are currently being targeted for zstd and br-based dictionaries.
\ne.g. delta-updates of a 50MB wasm file or a dictionary with the common HTML template code from a given site
", "time": "2023-11-09T14:31:39Z"}, {"author": "Kazuho Oku", "text": "I wonder if clients are going to have size limit on the files that they will consider as dictionaries. Like, if the server sends 10MB js, is the client going to compress that to create a dictionary?
", "time": "2023-11-09T14:32:10Z"}, {"author": "Mike Bishop", "text": "@meetecho, can we repoint the speaker camera?
", "time": "2023-11-09T14:33:02Z"}, {"author": "Patrick Meenan", "text": "If the size of the dictionary exceeds what the client supports then the client just doesn't advertise the Available-Dictionary for future requests (fails to get used but fails safely)
", "time": "2023-11-09T14:33:11Z"}, {"author": "Lorenzo Miniero", "text": "Mike: done, thanks for the heads up!
", "time": "2023-11-09T14:33:29Z"}, {"author": "Patrick Meenan", "text": "Same happens if the total size of dictionaries blows some out of the client cache
", "time": "2023-11-09T14:33:31Z"}, {"author": "Mike Bishop", "text": ":+1:
", "time": "2023-11-09T14:33:38Z"}, {"author": "Kazuho Oku", "text": "Right, so the server cannot use a huge file as a dictionary, unless it can specify how many bytes should be used to construct the dictionary.
", "time": "2023-11-09T14:34:10Z"}, {"author": "Kazuho Oku", "text": "That would be sad (or concerning) for websites having jquery.js or whatever a common javascript file that could be a bit on the larger side.
", "time": "2023-11-09T14:34:44Z"}, {"author": "Jonathan Hoyland", "text": "Grump grump grump. It's a channel binding, not a nonce.
", "time": "2023-11-09T14:35:01Z"}, {"author": "Mike Bishop", "text": "This decision makes me sad, but I understand the reasons.
", "time": "2023-11-09T14:36:00Z"}, {"author": "Timothy Terriberry", "text": "My use case might not be the highest-priority or most sophisticated, but being able to specify a limit addresses my issue and also seems to have some more general usefulness.
", "time": "2023-11-09T14:37:04Z"}, {"author": "Julian Reschke", "text": "Chairs: I have no news about QUERY right now, but I did review the open issues, and I still think that a focused design team telco could speed things up.
", "time": "2023-11-09T14:38:01Z"}, {"author": "Patrick Meenan", "text": "On the limit, does that differ significantly from being able to load a 32kb dictionary that was specifically constructed?
\nRequiring clients to support extracting a range out of a response to use as a dictionary is certainly doable but feels like a fair bit of additional complexity.
", "time": "2023-11-09T14:41:55Z"}, {"author": "David Oliver", "text": "Tommy, we have not used our implementation in practical tests
", "time": "2023-11-09T14:43:57Z"}, {"author": "Timothy Terriberry", "text": "So, if you're not familiar with SDP in WebRTC, the way it gets used is there is an offer/answer negotiation where the same SDP gets sent back and forth between two parties with minor edits.
", "time": "2023-11-09T14:44:19Z"}, {"author": "David Oliver", "text": "We have only prepared for IETF interop on the protocol definition
", "time": "2023-11-09T14:44:23Z"}, {"author": "Timothy Terriberry", "text": "With a lot of participants in a conference, it can get quite large (well over 32 kB).
", "time": "2023-11-09T14:44:59Z"}, {"author": "Timothy Terriberry", "text": "But simply using the (start of) the previous version of the SDP as a dictionary can get that down from ~300 kB to under 1.5kB (so it fits in an MTU).
", "time": "2023-11-09T14:45:57Z"}, {"author": "Julian Reschke", "text": "(see msg above)
", "time": "2023-11-09T14:46:14Z"}, {"author": "Julian Reschke", "text": "Proposal: I'll send out a summary during next week.
", "time": "2023-11-09T14:46:39Z"}, {"author": "Timothy Terriberry", "text": "You could send a fixed dictionary out of band, and that would probably provide some benefit, but using the data you already sent saves a lot.
", "time": "2023-11-09T14:46:39Z"}, {"author": "Patrick Meenan", "text": "I'll read up on SDP first and touch base. Mind opening an issue in the github repository and tagging compression-dictionary? https://github.com/httpwg/http-extensions/issues
", "time": "2023-11-09T14:47:59Z"}, {"author": "Lucas Pardue", "text": "this is a dispack
", "time": "2023-11-09T14:52:50Z"}, {"author": "Alan Frindell", "text": ":wave:
", "time": "2023-11-09T14:53:22Z"}, {"author": "Julian Reschke", "text": "would be nice to have the same mechanism for H2, no?
", "time": "2023-11-09T14:57:45Z"}, {"author": "David Benjamin", "text": "This feels like it should either be an h3.1 ALPN (if we don't need to do this very often) or we revive ALPS. Lifting QPACK all the way to TLS seems a bit much.
", "time": "2023-11-09T14:57:50Z"}, {"author": "Alex Chernyakhovsky", "text": "Isn't this just a subset of what ALPS was supposed to provide? Why not just bring back ALPS?
", "time": "2023-11-09T14:58:34Z"}, {"author": "Nick Banks", "text": "Why don't we expose a way for apps to leverage the QUIC transport parameters instead?
", "time": "2023-11-09T14:58:51Z"}, {"author": "Mike Bishop", "text": "That's definitely one of the open points of discussion. There's no reason this couldn't be a setting, except that it has to be processed before any requests are encoded.
", "time": "2023-11-09T14:58:58Z"}, {"author": "David Benjamin", "text": "(I have no opinion about ALPN vs ALPS here.)
", "time": "2023-11-09T14:59:26Z"}, {"author": "Lucas Pardue", "text": "I think the technical details would differ for H2; the feature of allow static table agility should not be version restricted IMO
", "time": "2023-11-09T14:59:34Z"}, {"author": "David Benjamin", "text": "Mike Bishop said:
\n\n\nThat's definitely one of the open points of discussion. There's no reason this couldn't be a setting, except that it has to be processed before any requests are encoded.
\n
Right, that's precisely the scenario ALPS was designed for.
", "time": "2023-11-09T14:59:46Z"}, {"author": "Alex Chernyakhovsky", "text": "I think I agree with davidben on ALPN vs ALPS, I just think \"not a special thing just for QPACK\"
", "time": "2023-11-09T15:02:10Z"}, {"author": "Erik Nygren", "text": "Wouldn't we need additional attributes in ALPS in the client hello? (Rather than just a list of ALPNs that support ALPS?)
", "time": "2023-11-09T15:02:44Z"}, {"author": "Eric Orth", "text": "But why did people object to ALPS? What would the likely objection be if we brought it back for this?
", "time": "2023-11-09T15:03:42Z"}, {"author": "David Benjamin", "text": "Erik Nygren said:
\n\n\nWouldn't we need additional attributes in ALPS in the client hello? (Rather than just a list of ALPNs that support ALPS?)
\n
ALPS is just an ALPN-specific byte string, so the ALPN protocol can decide what goes in there. For h2 and h3 we just said they were a sequence of frames, since that seemed most natural. So we'd just make a frame or SETTING and move on.
", "time": "2023-11-09T15:04:14Z"}, {"author": "David Schinazi", "text": "From memory, I think MT's objection to ALPS was that we didn't have enough of a use-case to justify the complexity
", "time": "2023-11-09T15:04:35Z"}, {"author": "Alex Chernyakhovsky", "text": "ALPS would let you fix this with more settings frames / new HTTP frame types once it's in. It's not a complete solution, unless you want to use the dynamic table.
", "time": "2023-11-09T15:04:35Z"}, {"author": "Mike Bishop", "text": "@Eric, the flow is weird for a TLS extension. If you put the client stuff in the ClientHello, it goes in the clear (modulo ECH), so ALPS doesn't -- it puts it later in the handshake.
", "time": "2023-11-09T15:04:40Z"}, {"author": "Alex Chernyakhovsky", "text": "@Mike Bishop isn't that only a concern until we do ECH?
", "time": "2023-11-09T15:05:15Z"}, {"author": "Mike Bishop", "text": "Hence \"modulo ECH\". :-)
", "time": "2023-11-09T15:05:39Z"}, {"author": "David Schinazi", "text": "ECH will never be applied to 100% of TLS connection
", "time": "2023-11-09T15:05:40Z"}, {"author": "David Benjamin", "text": "I believe another objection was an attempt to use TLS 1.3 half-RTT data, but half-RTT data is kinda weird and doesn't quite work. It especially doesn't work when you have a strong ordering requirement with the first request.
", "time": "2023-11-09T15:06:03Z"}, {"author": "David Benjamin", "text": "(I wrote draft-davidben-tls-alps-half-rtt discussing why half-RTT does not work well.)
", "time": "2023-11-09T15:06:23Z"}, {"author": "Erik Nygren", "text": "There seems to be a substantial overlap with what is needed here and how a client might signal support for Martin's proposal for controlling concurrent streams with the same model as quic.
", "time": "2023-11-09T15:06:24Z"}, {"author": "Alex Chernyakhovsky", "text": "@Mike Bishop oops, should have read the parenthetical :)
", "time": "2023-11-09T15:06:29Z"}, {"author": "Alan Frindell", "text": "Disabling the static table altogether (and maybe huffman) would make H3 coding much simpler for folks who don't care about perf
", "time": "2023-11-09T15:08:12Z"}, {"author": "Lucas Pardue", "text": "yep^^
", "time": "2023-11-09T15:08:24Z"}, {"author": "David Benjamin", "text": "Erik Nygren said:
\n\n\nThere seems to be a substantial overlap with what is needed here and how a client might signal support for Martin's proposal for controlling concurrent streams with the same model as quic.
\n
Right, feature and protocol negotiation are all just variations on \"I need a fixed connection-level property\". Which is basically the versioning (ALPN) vs independent extensions (ALPS) question.
", "time": "2023-11-09T15:08:31Z"}, {"author": "Alan Frindell", "text": "Looking at you, webtrans haters
", "time": "2023-11-09T15:08:32Z"}, {"author": "Alan Frindell", "text": "No offense taken!
", "time": "2023-11-09T15:09:21Z"}, {"author": "David Benjamin", "text": "Alan Frindell said:
\n\n\nDisabling the static table altogether (and maybe huffman) would make H3 coding much simpler for folks who don't care about perf
\n
IIRC that was also explicitly a use case for ALPS.
", "time": "2023-11-09T15:09:43Z"}, {"author": "Alan Frindell", "text": "Mike, do you remember the static table cut points for 2, 3 bytes?
", "time": "2023-11-09T15:09:43Z"}, {"author": "David Schinazi", "text": "WebTrans haters!? Where??? We're all enthusiasts here
", "time": "2023-11-09T15:09:47Z"}, {"author": "Erik Nygren", "text": "I guess TLS flags might be an option for some of these, but might not scale in the long-term.
\n(And/or has fingerprinting issues)
David Schinazi said:
\n\n\nWebTrans haters!? Where??? We're all enthusiasts here
\n
See you in moq
", "time": "2023-11-09T15:10:00Z"}, {"author": "David Benjamin", "text": "Erik Nygren said:
\n\n\nI guess TLS flags might be an option for some of these, but might not scale in the long-term.
\n
\n(And/or has fingerprinting issues)
No. Please let's not litter the TLS codepoint space with random individual h2 and h3 features. The whole point of designs like ALPN and ALPS is to give a clear separation here.
", "time": "2023-11-09T15:10:43Z"}, {"author": "Michael Toomim", "text": "At the point where we are updating the static table over time, that sure sounds like a dynamic table.
", "time": "2023-11-09T15:10:55Z"}, {"author": "Michael Toomim", "text": "Maybe we need better dynamic tables.
", "time": "2023-11-09T15:11:24Z"}, {"author": "David Benjamin", "text": "\"Dynamic\" here refers to stuff discovered over the course of a connection. What they're trying to solve here is pre-shared information.
", "time": "2023-11-09T15:11:46Z"}, {"author": "Michael Toomim", "text": "Understood, but maybe we are now noticing that this model of \"static\" and \"dynamic\" isn't quite holding up with practice.
", "time": "2023-11-09T15:12:14Z"}, {"author": "Alex Chernyakhovsky", "text": "I wonder if the name \"static table\" should have been \"initial table\"?
", "time": "2023-11-09T15:12:22Z"}, {"author": "Alan Frindell", "text": "Michael Toomim said:
\n\n\nAt the point where we are updating the static table over time, that sure sounds like a dynamic table.
\n
There's potential perf benefits. Referencing the static table is faster from a CPU perspective than mucking with the dynamic table
", "time": "2023-11-09T15:12:40Z"}, {"author": "David Benjamin", "text": "Yeah, I think this is just possibly awkward terminology, not an issue with the model itself.
", "time": "2023-11-09T15:12:57Z"}, {"author": "Michael Toomim", "text": "Perhaps we could refer to an \"initial table\" via a URL, rather than via IANA.
", "time": "2023-11-09T15:13:19Z"}, {"author": "Julian Reschke", "text": "sounds like ... dictionaries...
", "time": "2023-11-09T15:13:29Z"}, {"author": "Eric Orth", "text": "\"Less dynamic than the dynamic table table\"
", "time": "2023-11-09T15:13:33Z"}, {"author": "Erik Nygren", "text": "Although if ALPS doesn't provide enough information for the server to make an ALPN decision then there may still be tension for having a small number of per-ALPN flags in the client hello.
", "time": "2023-11-09T15:13:39Z"}, {"author": "David Benjamin", "text": "Erik Nygren said:
\n\n\nAlthough if ALPS doesn't provide enough information for the server to make an ALPN decision then there may still be tension for having a small number of per-ALPN flags in the client hello.
\n
Huh? ALPS is decided after ALPN. Can you clarify what the concern is here? I don't see why this use case would need to feed into an ALPN decision.
", "time": "2023-11-09T15:14:17Z"}, {"author": "Jonathan Hoyland", "text": "Maybe we need http-ops?
", "time": "2023-11-09T15:14:39Z"}, {"author": "Mike Bishop", "text": "No, the static table is not an initial table -- it's a distinct table that always stays in range, while dynamic entries roll off as the table filles up.
", "time": "2023-11-09T15:14:43Z"}, {"author": "Alan Frindell", "text": "H2 cut points are slightly different so you might organize the same set of headers differently?
", "time": "2023-11-09T15:14:50Z"}, {"author": "Mike Bishop", "text": "@Alan, I don't remember the cut-points off the top of my head, but it should be easy enough to reconstruct them.
", "time": "2023-11-09T15:15:32Z"}, {"author": "Alan Frindell", "text": "14 comes to mind and then ... shrug
", "time": "2023-11-09T15:15:54Z"}, {"author": "Alan Frindell", "text": "I think \"whose performance data\" is an interesting question. Different tables will impact different client/server pairs differrently
", "time": "2023-11-09T15:16:58Z"}, {"author": "Erik Nygren", "text": "Not this case, but for the \"I support the quic style concurrent streams model for h2\" (which might feed into whether a server selects h2 or http/1.1). But maybe that's where alpn \"h2.1\" ends up showing up.
", "time": "2023-11-09T15:17:02Z"}, {"author": "Alex Chernyakhovsky", "text": "David Benjamin said:
\n\n\nHuh? ALPS is decided after ALPN. Can you clarify what the concern is here? I don't see why this use case would need to feed into an ALPN decision.
\n
I found the diagram at https://datatracker.ietf.org/doc/html/draft-vvv-tls-alps-01#name-wire-protocol helpful
", "time": "2023-11-09T15:18:29Z"}, {"author": "David Benjamin", "text": "Erik Nygren said:
\n\n\nNot this case, but for the \"I support the quic style concurrent streams model for h2\" (which might feed into whether a server selects h2 or http/1.1). But maybe that's where alpn \"h2.1\" ends up showing up.
\n
Yeah, that sounds solidly like an \"h2.1\" thing. This is the usual tradeoff between ordered versions and independent a la carte extensions. I haven't been following the streams issue as carefully, but since it sounds like a \"oops, we goofed and got this wrong\" situation, versioning sounds better.
", "time": "2023-11-09T15:20:25Z"}, {"author": "David Benjamin", "text": "(To that end, the reason I said the QPACK table could be ALPN or ALPS is that if we just do this very infrequently and just add to the list, updating the table every several years when we want a minor rev of the protocol is perfectly fine.)
", "time": "2023-11-09T15:22:52Z"}, {"author": "Lucas Pardue", "text": "\n\nIf you work on a browser, you will often hear remarks like, Why don't you just put [popular framework] in the browser?
\n
\n\n", "time": "2023-11-09T15:23:56Z"}]This is a good question \u2014 or at least it illuminates how browser teams think about tradeoffs. Spoiler: it's gnarly.
\n