W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: HTTP router point-of-view concerns

From: Mike Belshe <mike@belshe.com>
Date: Fri, 12 Jul 2013 02:11:30 -0700
Message-ID: <CABaLYCs4KUXO2YwGyG07kbGJtrrfc7kVMJH3N_f=D-WQG86FcQ@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: httpbis mailing list <ietf-http-wg@w3.org>
I'm also in favor of removing the compressor completely.

The reason is because we've seen the "negotiable compression protocol"
movie before.  At this point, its negotiable, and therefore just a big time
sink.  In the end, it will not be deployed because some player will have a
bug forcing everyone else to turn it off to avoid the hassle.   I apologize
if this sounds pessimistic - but history shows that this is a likely result.

If we can't agree on mandatory compression (which was long ago thrown out)
why not just add session state.  Cookies & User Agents can be set as state
which applies across all streams and be done.  It's mandatory, its super
simple, it fixes the single biggest redundant-bandwidth problem elegantly,
and in the end, I think this is basically what pkh and christian are asking
for under different names.

We'll probably save a lot of time debating and end up with a protocol which
is almost as good as a true compressor.

On Fri, Jul 12, 2013 at 1:26 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 12/07/2013 7:35 a.m., Roberto Peon wrote:
>> I think it is perfectly reasonable for an intermediary to set the
>> compression size to zero if it wishes.
>> Market forces will (in the long-term) pick the correct strategy for
>> this-- assuming the compression is effective at reducing latency, and that
>> people care about latency reductions, then eventually intermediaries might
>> evolve to use it.
>> If it is ineffective at reducing latency, or if reduced latency is not
>> actually desirable, then intermediaries would not use it.
>> The DoS vector you're talking about is not a DoS vector if the
>> intermediary resets all streams before the change-of-state-size comes into
>> effect.
> If you means RST_STREAM on all the initial streams which use a larger
> compression size then what you are doing is adding an RTT penalty to all
> those requests over and beyond what HTTP/1 suffers from already on a normal
> transaction. This is not a useful way forward (wastes packets, RTT and
> stream IDs) and resolving it is to make decompression with the default
> state size mandatory for all recipients. Which brings us full circle on the
> problem of having a default >0 in the dynamic part of the state tables.
>  When the state size is 0, one should be able to use some kinds of
>> 'indexed' representations, so long as those representations refer only to
>> items in the static tables. Why do you believe that this would use more or
>> less CPU? (It should use less CPU and less memory...)
> I did not mention CPU. Only the bandwidth amplification effects that
> agents disabling compression would incur and need to consider carefully.
> Personally I would like to see a 127 entry mandatory static table in the
> spec itself and tied to the "2.0" version with a 127 entry optional dynamic
> table indicated by the high-end bit of the byte code. With a capacity byte
> size for dynamic table sent each way and senders forbidden to add new
> entries to the dynamic table until they hold the value from both ends of
> the connection. Agreed value being the minimum of both ends capacities.
> Amos
Received on Friday, 12 July 2013 09:11:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC