Re: #466 segment compression

I don't disagree with Roberto's general point, because as spec'd a big
difference between the two is that *all* intermediaries need to deal with
decompressing per-frame-compressed streams. Even intermediaries which are
strictly HTTP/2, which mux large numbers of streams, and are otherwise
happy to forward compressed content: a downstream client may not allow that
compressed content to be forwarded.

On the other hand, the only implementations which *must* decompress
implicit c-e: gzip streams are ones which intermediate with 1.1 clients or
receiving applications expecting uncompressed content.

The key here, as you suggested earlier, is whether 2.0 clients are mandated
to receive compression (whether frame-by-frame, or implicit c-e: gzip, or
some other means). This appears to be the out.

cheers,
-johnny


On Fri, May 2, 2014 at 3:54 AM, <K.Morgan@iaea.org> wrote:

>  On Friday,02 May 2014 05:13, jgraettinger@google.com wrote:
>
> > The HTTP/1.1 pipelined case is equivalent to using
> MAX_CONCURRENT_STREAMS of 1.
>
> > That also guarantees a single compression context. Many HTTP/2
> implementations are
>
> > likely willing to deal with N > 1 simultaneous compression contexts in
> exchange for better
>
> > compression, so long as they can dictate the upper bound (and indeed
> they can).
>
>
>
> Agreed.  Just to be clear, you're saying you disagree with what Roberto
> said (see below) that to bound the state/memory requirements a server would
> have to disable multiplexing?
>
>
>
> **You can't claim it's a problem for T-E and then out of the other side of
> your mouth say it's not a problem for dynamic C-E.**
>
>
>
>
>
> On Tuesday,29 April 2014 21:58, grmocg@gmail.com wrote:
>
> > If compression is per-segment as opposed to per-frame
>
> >    AND we wish to restrict the amount of state the server must keep
> around
>
> >    AND the sender wishes to have all the data in the segment compressed
>
> >   THEN then the segment being compressed must be sent in its entirety in
> a contiguous series of frames with no muxing of other streams in the middle.
>
> >
>
> > If one doesn't do this, then the server is forced to retain this state
> indefinitely, though the client is allowed to make progress on other
> streams.
>
> > This likely masks the consumption of server-state from the user, and
> also denies the user(and client) the ability to do compression for any
> other stream.
>
> >
>
> > If one does this, then one effectively loses the multiplexing feature of
> the protocol.
>
> >
>
> > Arguably, this is worse than simply doing per-frame compression,
> especially when on considers that with relatively decent frame sizes, the
> marginal benefit
>
> > of continuing the compression context across frames is likely small.
>
>
>
>
>
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>

Received on Friday, 2 May 2014 16:19:37 UTC