Re: #466 segment compression

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

> I'm not arguing the utility of t-e versus c-e (we all know c-e is more
> widely used - and abused). The point of Martin's issue #466 was (I believe)
> whether or not we can do per-segment t-e instead of per-frame t-e. Each has
> it's advantages and disadvantages.
>
> The point of your argument, I thought, was the state commitment of the
> server for per-segment t-e. You said, "If compression is per-segment as
> opposed to per-frame
>    AND we wish to restrict the amount of state the server must keep
> around..."
>
> The DoS potential is on which receiver? The end client or the
> intermediaries? For end clients it's the same surface area as c-e gzip. For
> intermediaries, it's only a problem, as you pointed out if support for t-e
> is mandated and so 2->1.x gateways have to do a lot of de-compression. So I
> would just make it explicit opt-out rather than opt in. That lets
> intermediaries opt out for clients coming from 1.X without a TE: gzip
> header.
>

By receiver I mostly mean the server-side, and a proxy is both a client and
a server. I am less concerned about the server , amusingly, than I am about
the server-side of a proxy.
Servers are often dealing with orders of magnitude less concurrency and
bandwidth, and can adopt alternate strategies to cope with these things.
For large deployments it is the proxies which bear these
scalability/availability concerns and protect the servers from them.

I'm, in general, not concerned about the memory usage of user-agents in
terms of DoS. They're unlikely to be the recipients of a DoS and can limit
themselves as necessary to prevent OOM, etc. without negatively affecting
other users.


>
> But again, the point of this thread is to figure out if per-segment t-e is
> tenable and whether it's a better solution than per-frame t-e.
>

In a world where we've killed off c-e, per-frame t-e presents a far smaller
DoS profile than per-segment t-e.
The biggest downside to per-frame t-e is that it encourages intermediary
design which forwards frames as-received, which honestly, doesn't seem like
a huge downside.

For my part, I'd be encouraging people to not implement t-e gzip if it was
per-segment, and I'd be advocating for people to implement it if it was
per-frame. This obviously would include Google's implementations.
-=R


>
> -Keith
>
> P.S. Roberto, my other questions are in the thread "Making Implicit C-E
> Work". Here is a link to my email
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0558.html
>
>
> On May 2, 2014, at 23:13, "grmocg@gmail.com<mailto:grmocg@gmail.com>" <
> grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote:
>
>
>
>
> On Fri, May 2, 2014 at 1:51 PM, <K.Morgan@iaea.org<mailto:
> 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
>
>
> 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.
>