Re: #466 segment compression

On 02.05.2014 21:37, Roberto Peon wrote:
>
> Theoretically Keith is correct about intermediaries needing to 
> decompress with c-e gzip.
>
Intermediaries are already decompressing with c-e gzip.
>
> In practice, though, Johnny (and I guess) is also right- Since almost 
> all traffic comes from clients which support c-e gzip, intermediaries 
> will not need to decompress the vast majority of the time.
>
> The opposite is true for a-e gzip, unfortunately.
> Almost no clients support it, thus the intermediary is almost always 
> decompressing, and it also thus has poor discrimination between 
> malicious and innocent actors. In other words the DoS surface area is 
> very much bigger.
>
For potential HTTP2 server, clients, intermediaries this can be avoided 
by mandating t-e gzip (assuming t-e was meant). Then only gateways 
between the worlds would regularly need to decompress. For the majority 
of the traffic this would not be necessary even for those gateways as 
the content is compressed differently like video, audio, images or is 
send uncompressed.

Roland
>
> The difference in real behavior is thus large, all due to the fact 
> that c-e gzip has far better support in deployed implementations.
>
> -=R
>
> On May 2, 2014 11:42 AM, <K.Morgan@iaea.org 
> <mailto:K.Morgan@iaea.org>> wrote:
>
>     You missed the first sentence of Roberto's statement:
>     "If compression is per-segment as opposed to per-frame..."
>
>     We're talking about per-segment t-e. He argued against per-segment
>     t-e by claiming that it would be such a huge state/memory
>     commitment on the sender that you would have to give up
>     multiplexing. If that's true, then it's also true for dynamic c-e
>     and you better rethink the whole protocol. If it's not true then
>     there is no argument against per-segment t-e. So either it's true
>     or it isn't.
>
>     Your argument against frame-by-frame compression is also wrong -
>     or you're describing a dumb intermediary implementation. If the
>     downstream hop doesn't accept t-e, then the intermediary shouldn't
>     have negotiated for t-e with the upstream hop in the first place.
>     It doesn't _have_ to do anything.
>
>     On the other hand, if support were to be mandated in 2.0, then an
>     intermediary could always merrily forward compressed content;
>     except to 1.X - same as for the current version of implicit c-e.
>
>     -Keith
>
>
>     On May 2, 2014, at 18:23, "jgraettinger@chromium.org
>     <mailto:jgraettinger@chromium.org><mailto:jgraettinger@chromium.org <mailto:jgraettinger@chromium.org>>"
>     <jgraettinger@chromium.org
>     <mailto:jgraettinger@chromium.org><mailto:jgraettinger@chromium.org <mailto:jgraettinger@chromium.org>>>
>     wrote:
>
>     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
>     <mailto:K.Morgan@iaea.org><mailto:K.Morgan@iaea.org
>     <mailto:K.Morgan@iaea.org>>> wrote:
>
>     On Friday,02 May 2014 05:13, jgraettinger@google.com
>     <mailto:jgraettinger@google.com><mailto:jgraettinger@google.com
>     <mailto: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
>     <mailto:grmocg@gmail.com><mailto:grmocg@gmail.com
>     <mailto: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.
>
>
>     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.
>