Re: HTTP router point-of-view concerns

[Mike Belshe <[e-mail]>]

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.
Mike



On Fri, Jul 12, 2013 at 1:26 AM, Amos Jeffries <[e-mail]> 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
>
>