Re: #466 segment compression

On Fri, May 2, 2014 at 1:51 PM, <K.Morgan@iaea.org> wrote:

> Once again, intermediaries never _have_ to put themselves in a situation
> where they have to decompress t-e. If the downstream requestor didn't
> support t-e, the intermediary is stupid to request t-e upstream (unless it
> wants to decompress).
>

So, that effectively says that one can never use t-e, since the majority of
downstream entities don't support it (or as spec'd, didn't send it to begin
with).
That would mean that t-e was practically useless, then.

This is as compared to c-e gzip, which almost all endpoints support, and
which can thus give the benefit of payload compression on almost everything.


>
> (Roberto) your main point on this thread was that the DoS potential was on
> the _sender_.


I was worried about proxies. The DoS potential is on the receiver, not the
sender. It just so happens that for proxies, they're both receivers and
senders.


> Furthermore you said it was so bad it would require getting rid of
> multiplexing to reduce the DoS surface area. Johnny disagreed because you
> can bound the problem by setting max_concurrent_streams appropriately. Do
> you agree with Johnny? If so, then there's also no such DoS for per-segment
> t-e.
>
>
Johnny and I are saying the same thing, though: Reducing
MAX_CONCURRENT_STREAMS *is* getting rid of multiplexing... at
MAX_CONCURRENT_STREAMS == 1, there is no multiplexing. At any level under
that which we'd otherwise be happy to support, you're partially getting rid
of it.




> -Keith
>
> P.S. Roberto, I'm really interested in your response to my questions
> regarding your proposal to keep implicit c-e gzip.
>
>
I'm a bit lost in the thread-- would you mind repeating the questions you
want me to address here again? There are a mountain of quotes and it gets
very difficult to read. :/

-=R