Subject: Inter-Stream Compression and Delta Encodings

From: Patrick McManus <[email-masked]>
Date: Mon, 24 Apr 2017 21:07:44 -0400

Hi WG!

Right before we met in Chicago Vlad updated his compression draft - I'll
highlight it here in case you lost it in the shuffle of the meeting (as I
did originally).
https://datatracker.ietf.org/doc/draft-vkrasnov-h2-compression-dictionaries/?include_text=1
He presented on this in Seoul (and that means it is in the meetecho video
archive if you missed it
http://oldrecs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_HTTPBIS_II&chapter=chapter_1
)

I would like to start a discussion on whether the working group has an
interest in adopting  a work item in this general area (which may or may
not be this draft depending on consensus). The general topic is recurring,
and I know of interest from at least three parties - though other than Vlad
(who has submitted a draft!) they should speak for themselves in this
thread. But the chairs would need to hear a wider array of viewpoints
before asking the group to take on the burden.

To summarize the top level pros and cons:
 Pro: saves lots of bytes and serialization time (vlad had data on that you
can find in the ietf 97 meeting materials). arguably also fixes a
regression from h1 where h2 discourages inlining which results in less
efficient content-encodings.

Con: mixing compression and encryption is a scary business - ala CRIME.
Vlad's draft attempts to address this by creating different sets of
compression contexts and letting the clients determine the sets and the
servers determine whether or not they will compress individual resources
within those sets.

Does the working group think that is a mechanism that can be effectively
used in a safe way? Thanks for your comments.

-Patrick

-- here are a few drive-by review comments from a first take on the text --

I guess the settings is c->s with encodings flowing s->c. We often manage
to make these things symmetrical can this operate in the other direction
too? We've long lamented content-encoding: gzip not working well in h1 POST
e.g.

what's the interaction with push?

set_compression_context default should probably be 254 to be conservative
rather than 0.

set_dictionary can't be "set on any stream" - subject to opt in

 - If not enough DATA was
   sent, the Dictionary for the given ID is considered uninitialized
   vs
   "If Size is greater than the length of the
      transmitted data, then all of the data will be used."

having a definiton for a context very early in the document would help..
maybe "a context is a non-overlapping set of response streams and
dictionaries"

h1 bindings in a document with for h2 in its title is weird. I would just
get rid of the h1 definitions completely - it has a much richer tradition
of transaction independence on a persistent connection and things that have
tried to bypass that (e.g. connect auth) have a checkered history.

"In addition when binary data is expected on the stream, the clinet SHOULD
hint to the server by sending a SET_COMPRESSION_CONTEXT with the special
value of 255." This is really better advice to the server than anything a
client should be guessing. There are N representations potentially each
with a unique MIME type as possible responses for a request.

"If a USE_DICTIONARY frame arrives for an uninitialized dictionary, this is
considered as stream error of type COMPRESSION_ERROR." Given the cross
stream nature of this - that's probably a protocol error. Any decoding
error is probably a protocol error too.

what does it mean for the extension to be disabled by default? Is that
something different than the SETTINGS frame, or are you informing how the
server config switches need to work?

probably not enough bits for contexts (and maybe dictionaries).

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Apr 2017 11:43:45 +1000

On 25 April 2017 at 11:07, Patrick McManus <[email-masked]> wrote:
> can find in the ietf 97 meeting materials). arguably also fixes a regression
> from h1 where h2 discourages inlining which results in less efficient
> content-encodings.

This is overstating the case.  The point is that h2 doesn't do enough
to encourage servers to split resources.  This helps provide more
incentive to do that, by helping to remove the compression cost that
comes with that.

We also have to consider the alternative designs in this space (SDCH
primarily), which have some different trade-offs.

Leaving aside the security concerns (which I think still need more
work) I find the current design as proposed by Vlad to be a little too
complex.

This proposes both orthogonal version negotiation and compression
negotiation on top of the feature negotiation that uses the setting.
Version negotiation can be implied by the setting, and a single
compressor (brotli seems like a reasonable choice) is much easier to
manage.

The HTTP/1.1 mapping is complicated by the need to add a header field
with the same sort of complexity as the h2 setting.  In comparison,
SDCH just uses Accept-Encoding.  SDCH also performs better for
short-lived connections by virtue of relying on the cache.

The size attribute on SET_DICTIONARY adds the need to truncate data
(but what data?  from the start of the stream or from the point at
which the frame is received).

Why does the client send SET_COMPRESSION_CONTEXT?  I mean, how can it
know that different resources are compressible together without
actually knowing what they contain?

I see why you might want to specifically suppress compression on a
given request, but why provide two different ways to do this?  I
understand that one prohibits compression and the other prohibits both
compression and reference, but it's hard to understand why you would
benefit from not compressing a stream that is later used as a
reference.

Ordering is underspecified here.  If two concurrent streams reference
the same dictionary, how are interleaved DATA frames accumulated into
the dictionary?

This extension is a great example of something in h2 that wouldn't
work in QUIC.  Cross-stream ordering guarantees are non-existent in
QUIC.  It would be nice to understand what a design for QUIC would
look like.