Re: #466 segment compression

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.

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.

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

Received on Friday, 2 May 2014 21:50:30 UTC