Subject: RE: #466 segment compression

From: <[email-masked]>
Date: Thu, 1 May 2014 22:01:24 +0000

On 29 April 2014 21:57, [email-masked] wrote:
> If compression is per-segment as opposed to per-frame
>    AND we wish to restrict the amount of state the server must keep around
>    AND the sender wishes to have all the data in the segment compressed
>   THEN then the segment being compressed must be sent in its entirety in a contiguous series of frames with > no muxing of other streams in the middle.

The exact same problem exists for dynamic compression with C-E.  How are you going to solve that?

> I'm still worried: There is an assumption here that the originator of the stream actually knows the provenance

> of the various data within. This is often a hard problem especially given that servers and services are not

> currently architected to keep track of provenance. IMHO, if a segment/frame wasn't compressed it should

> never be compressed. That leads to safety.

I still don't understand this security argument with respect to intermediaries being able to add compression. I'm probably missing something.  Please enlighten me.

Compression is only a concern within TLS, right (e.g. BREACH etc.)? So...

1. If TLS is end-to-end, intermediaries can't touch anything anyway because they just see encrypted data.

2. If the TLS starts at a forward proxy, the proxy could change the compression when the data come out of the encryption tunnel before sending the data back to the client.  But at that point there is no security anyway.

3. If the TLS ends at a reverse proxy... this is the only potential problem I could think of because the intermediary could add compression "without provenance" before the data enter the tunnel.  But the reverse proxy by definition already has a relationship with the server, right? So the configuration should be set up such that the reverse proxy doesn't add compression.

4. If there is a break in the TLS somewhere in the middle?  That's not secure by definition.

> If the proposal is simply that if any frame in a segment is compressed all of something in a
> segment can be compressed, sure. I'm on board with that.

Yes, that's what I was saying - if we stick with frame-by-frame compression.

On Tue, Apr 29, 2014 at 1:41 AM, <[email-masked]> wrote:

I think the simplest idea is to require the origin to separate attacker-controlled data and private/confidential data by segments.  All of the rest of the intermediary problems go away since an intermediary already can’t re-frame across segment boundaries, plus it allows an intermediary to do whatever it wants within a segment (compress/uncompress/concatenate/de-compress+re-compress).

The thing I like about Martin’s idea to switch to one compression context per segment is that it provides greater compatibility between HTTP/1.x T-E and HTTP/2 transfer codings.  Per-frame compression as we have it now is compatible with T-E when going from 2 -> 1.x, but it’s not compatible from 1.x -> 2.  The added complexity and the “vast increase in DoS surface area” [1] is a big deal though.

[1] https://github.com/http2/http2-spec/issues/466#issuecomment-41361711

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.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 May 2014 15:39:53 -0700

On 1 May 2014 15:01,  <[email-masked]> wrote:
> TLS is end-to-end

Your argument assumes the existence of only one pair of ends.  If you
look at the sorts of large deployments the likes of what Roberto might
have worked on in the past, there are multiple hops, but all of those
hops are encrypted.  The same is true of all the "trusted proxy"
scenarios (though I'll note that this requires a very expansive
definition of "trusted").  These concerns are very real for those
scenarios.  When looking at this holistically, there are cases where
data hits multiple TLS-protected hops.

---

From: <[email-masked]>
Date: Thu, 1 May 2014 22:42:28 +0000

> The exact same problem exists for dynamic compression with C-E.  How are you going to solve that?

Sorry to reply to my own e-mail, but I really think this does apply to dynamic C-E compression and is a DoS vector.

Suppose a client sends N request for various entities that are dynamically compressed, where N=MAX_CONCURRENT_STREAMS and suggests an equal priority for each. If the server gives equal priority to serving each stream, it will have N outsanding compression contexts until all requests are serviced. By contrast, in HTTP/1.1, even with pipelining, a single client on a single connection would only ever require one compression context on the server to service its requests.

This is an argument in favor of using frame-by-frame compression for dynamic compression since frame-by-frame compression _can_ be implemented with only one outstanding compression context at any given time.  It's also an argument for mandating client *support* for frame-by-frame gzip (i.e. non-optional) because it always gives servers a way out from this DoS vector.

Has anybody implemented a native HTTP/2 server with dynamic compression support that can speak to this problem?
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.

---

From: Johnny Graettinger <[email-masked]>
Date: Thu, 1 May 2014 23:12:38 -0400

The HTTP/1.1 pipelined case is equivalent to using MAX_CONCURRENT_STREAMS
of 1. That also guarantees a single compression context. Many HTTP/2
implementations are likely willing to deal with N > 1 simultaneous
compression contexts in exchange for better compression, so long as they
can dictate the upper bound (and indeed they can).

On Thu, May 1, 2014 at 6:42 PM, <[email-masked]> wrote:

> >>   THEN then the segment being compressed must be sent in its entirety
> in a contiguous series of frames with > no muxing of other streams in the
> middle.
> >
> Sorry to reply to my own e-mail, but I really think this does apply to
> dynamic C-E compression and is a DoS vector.
>
> Suppose a client sends N request for various entities that are dynamically
> compressed, where N=MAX_CONCURRENT_STREAMS and suggests an equal priority
> for each. If the server gives equal priority to serving each stream, it
> will have N outsanding compression contexts until all requests are
> serviced. By contrast, in HTTP/1.1, even with pipelining, a single client
> on a single connection would only ever require one compression context on
> the server to service its requests.
>
> This is an argument in favor of using frame-by-frame compression for
> dynamic compression since frame-by-frame compression _can_ be implemented
> with only one outstanding compression context at any given time.  It's also
> an argument for mandating client *support* for frame-by-frame gzip (i.e.
> non-optional) because it always gives servers a way out from this DoS
> vector.
>
> 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.
>
>

---

From: <[email-masked]>
Date: Fri, 2 May 2014 07:54:57 +0000

On Friday,02 May 2014 05:13, [email-masked]<mailto:[email-masked]> wrote:

> The HTTP/1.1 pipelined case is equivalent to using MAX_CONCURRENT_STREAMS of 1.

> That also guarantees a single compression context. Many HTTP/2 implementations are

> likely willing to deal with N > 1 simultaneous compression contexts in exchange for better

> compression, so long as they can dictate the upper bound (and indeed they can).

Agreed.  Just to be clear, you're saying you disagree with what Roberto said (see below) that to bound the state/memory requirements a server would have to disable multiplexing?

*You can't claim it's a problem for T-E and then out of the other side of your mouth say it's not a problem for dynamic C-E.*

>   THEN then the segment being compressed must be sent in its entirety in a contiguous series of frames with no muxing of other streams in the middle.

> If one doesn't do this, then the server is forced to retain this state indefinitely, though the client is allowed to make progress on other streams.

> This likely masks the consumption of server-state from the user, and also denies the user(and client) the ability to do compression for any other stream.

> If one does this, then one effectively loses the multiplexing feature of the protocol.

> Arguably, this is worse than simply doing per-frame compression, especially when on considers that with relatively decent frame sizes, the marginal benefit

> of continuing the compression context across frames is likely small.

---

From: Johnny Graettinger <[email-masked]>
Date: Fri, 2 May 2014 12:19:09 -0400

I don't disagree with Roberto's general point, because as spec'd a big
difference between the two is that *all* intermediaries need to deal with
decompressing per-frame-compressed streams. Even intermediaries which are
strictly HTTP/2, which mux large numbers of streams, and are otherwise
happy to forward compressed content: a downstream client may not allow that
compressed content to be forwarded.

On the other hand, the only implementations which *must* decompress
implicit c-e: gzip streams are ones which intermediate with 1.1 clients or
receiving applications expecting uncompressed content.

The key here, as you suggested earlier, is whether 2.0 clients are mandated
to receive compression (whether frame-by-frame, or implicit c-e: gzip, or
some other means). This appears to be the out.

cheers,
-johnny

On Fri, May 2, 2014 at 3:54 AM, <[email-masked]> wrote:

>  On Friday,02 May 2014 05:13, [email-masked] wrote:
>
> Agreed.  Just to be clear, you're saying you disagree with what Roberto
> said (see below) that to bound the state/memory requirements a server would
> have to disable multiplexing?
>
>
>
> **You can't claim it's a problem for T-E and then out of the other side of
> your mouth say it's not a problem for dynamic C-E.**
>
>
>
>
>
> On Tuesday,29 April 2014 21:58, [email-masked] wrote:
>
> >   THEN then the segment being compressed must be sent in its entirety in
> a contiguous series of frames with no muxing of other streams in the middle.
>
> >
>
> > If one doesn't do this, then the server is forced to retain this state
> indefinitely, though the client is allowed to make progress on other
> streams.
>
> > This likely masks the consumption of server-state from the user, and
> also denies the user(and client) the ability to do compression for any
> other stream.
>
> >
>
> > Arguably, this is worse than simply doing per-frame compression,
> especially when on considers that with relatively decent frame sizes, the
> marginal benefit
>

---

From: <[email-masked]>
Date: Fri, 2 May 2014 18:41:54 +0000

You missed the first sentence of Roberto's statement:
"If compression is per-segment as opposed to per-frame..."

We're talking about per-segment t-e. He argued against per-segment t-e by claiming that it would be such a huge state/memory commitment on the sender that you would have to give up multiplexing. If that's true, then it's also true for dynamic c-e and you better rethink the whole protocol. If it's not true then there is no argument against per-segment t-e. So either it's true or it isn't.

Your argument against frame-by-frame compression is also wrong - or you're describing a dumb intermediary implementation. If the downstream hop doesn't accept t-e, then the intermediary shouldn't have negotiated for t-e with the upstream hop in the first place. It doesn't _have_ to do anything.

On the other hand, if support were to be mandated in 2.0, then an intermediary could always merrily forward compressed content; except to 1.X - same as for the current version of implicit c-e.

-Keith

On May 2, 2014, at 18:23, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

I don't disagree with Roberto's general point, because as spec'd a big difference between the two is that *all* intermediaries need to deal with decompressing per-frame-compressed streams. Even intermediaries which are strictly HTTP/2, which mux large numbers of streams, and are otherwise happy to forward compressed content: a downstream client may not allow that compressed content to be forwarded.

On the other hand, the only implementations which must decompress implicit c-e: gzip streams are ones which intermediate with 1.1 clients or receiving applications expecting uncompressed content.

The key here, as you suggested earlier, is whether 2.0 clients are mandated to receive compression (whether frame-by-frame, or implicit c-e: gzip, or some other means). This appears to be the out.

cheers,
-johnny

On Fri, May 2, 2014 at 3:54 AM, <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Roberto Peon <[email-masked]>
Date: Fri, 2 May 2014 12:37:36 -0700

Theoretically Keith is correct about intermediaries needing to decompress
with c-e gzip.

In practice, though, Johnny (and I guess) is also right- Since almost all
traffic comes from clients which support c-e gzip, intermediaries will not
need to decompress the vast majority of the time.

The opposite is true for a-e gzip, unfortunately.
Almost no clients support it, thus the intermediary is almost always
decompressing, and it also thus has poor discrimination between malicious
and innocent actors. In other words the DoS surface area is very much
bigger.

The difference in real behavior is thus large, all due to the fact that c-e
gzip has far better support in deployed implementations.

-=R
On May 2, 2014 11:42 AM, <[email-masked]> wrote:

> We're talking about per-segment t-e. He argued against per-segment t-e by
> claiming that it would be such a huge state/memory commitment on the sender
> that you would have to give up multiplexing. If that's true, then it's also
> true for dynamic c-e and you better rethink the whole protocol. If it's not
> true then there is no argument against per-segment t-e. So either it's true
> or it isn't.
>
> Your argument against frame-by-frame compression is also wrong - or you're
> describing a dumb intermediary implementation. If the downstream hop
> doesn't accept t-e, then the intermediary shouldn't have negotiated for t-e
> with the upstream hop in the first place. It doesn't _have_ to do anything.
>
> On the other hand, if support were to be mandated in 2.0, then an
> intermediary could always merrily forward compressed content; except to 1.X
> - same as for the current version of implicit c-e.
>
> -Keith
>
>
> On May 2, 2014, at 18:23, "[email-masked]<mailto:
> [email-masked]>" <[email-masked]<mailto:
> [email-masked]>> wrote:
>
> On the other hand, the only implementations which must decompress implicit
> c-e: gzip streams are ones which intermediate with 1.1 clients or receiving
> applications expecting uncompressed content.
>
> The key here, as you suggested earlier, is whether 2.0 clients are
> mandated to receive compression (whether frame-by-frame, or implicit c-e:
> gzip, or some other means). This appears to be the out.
>
> cheers,
> -johnny
>
>
> *You can't claim it's a problem for T-E and then out of the other side of
> your mouth say it's not a problem for dynamic C-E.*
>
>
>
>
>

---

From: Roland Zink <[email-masked]>
Date: Fri, 02 May 2014 22:06:04 +0200

On 02.05.2014 21:37, Roberto Peon wrote:
>
> Theoretically Keith is correct about intermediaries needing to 
> decompress with c-e gzip.
>
Intermediaries are already decompressing with c-e gzip.
>
> In practice, though, Johnny (and I guess) is also right- Since almost 
> all traffic comes from clients which support c-e gzip, intermediaries 
> will not need to decompress the vast majority of the time.
>
> decompressing, and it also thus has poor discrimination between 
> malicious and innocent actors. In other words the DoS surface area is 
> very much bigger.
>
For potential HTTP2 server, clients, intermediaries this can be avoided 
by mandating t-e gzip (assuming t-e was meant). Then only gateways 
between the worlds would regularly need to decompress. For the majority 
of the traffic this would not be necessary even for those gateways as 
the content is compressed differently like video, audio, images or is 
send uncompressed.

Roland
>
> The difference in real behavior is thus large, all due to the fact 
> that c-e gzip has far better support in deployed implementations.
>
> -=R
>
> On May 2, 2014 11:42 AM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     We're talking about per-segment t-e. He argued against per-segment
>     t-e by claiming that it would be such a huge state/memory
>     commitment on the sender that you would have to give up
>     multiplexing. If that's true, then it's also true for dynamic c-e
>     and you better rethink the whole protocol. If it's not true then
>     there is no argument against per-segment t-e. So either it's true
>     or it isn't.
>
>     Your argument against frame-by-frame compression is also wrong -
>     or you're describing a dumb intermediary implementation. If the
>     downstream hop doesn't accept t-e, then the intermediary shouldn't
>     have negotiated for t-e with the upstream hop in the first place.
>     It doesn't _have_ to do anything.
>
>     intermediary could always merrily forward compressed content;
>     except to 1.X - same as for the current version of implicit c-e.
>
>     -Keith
>
>
>     On May 2, 2014, at 18:23, "[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>"
>     <[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>
>     I don't disagree with Roberto's general point, because as spec'd a
>     big difference between the two is that *all* intermediaries need
>     to deal with decompressing per-frame-compressed streams. Even
>     intermediaries which are strictly HTTP/2, which mux large numbers
>     of streams, and are otherwise happy to forward compressed content:
>     a downstream client may not allow that compressed content to be
>     forwarded.
>
>     On the other hand, the only implementations which must decompress
>     implicit c-e: gzip streams are ones which intermediate with 1.1
>     clients or receiving applications expecting uncompressed content.
>
>     mandated to receive compression (whether frame-by-frame, or
>     implicit c-e: gzip, or some other means). This appears to be the out.
>
>     cheers,
>     -johnny
>
>
>     On Fri, May 2, 2014 at 3:54 AM, <[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>
>     On Friday,02 May 2014 05:13, [email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     Agreed.  Just to be clear, you're saying you disagree with what
>     Roberto said (see below) that to bound the state/memory
>     requirements a server would have to disable multiplexing?
>
>
>
>     *You can't claim it's a problem for T-E and then out of the other
>     side of your mouth say it's not a problem for dynamic C-E.*
>
>
>
>
>
>     On Tuesday,29 April 2014 21:58, [email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     >   THEN then the segment being compressed must be sent in its
>     entirety in a contiguous series of frames with no muxing of other
>     streams in the middle.
>
>     >
>
>     > If one doesn't do this, then the server is forced to retain this
>     state indefinitely, though the client is allowed to make progress
>     on other streams.
>
>     > This likely masks the consumption of server-state from the user,
>     and also denies the user(and client) the ability to do compression
>     for any other stream.
>
>     >
>
>     especially when on considers that with relatively decent frame
>     sizes, the marginal benefit
>
>     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.
>
>
>     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.
>

---

From: <[email-masked]>
Date: Fri, 2 May 2014 20:51:50 +0000

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

(Roberto) your main point on this thread was that the DoS potential was on the _sender_. 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.

-Keith

P.S. Roberto, I'm really interested in your response to my questions regarding your proposal to keep implicit c-e gzip.

On May 2, 2014, at 21:37, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Theoretically Keith is correct about intermediaries needing to decompress with c-e gzip.

In practice, though, Johnny (and I guess) is also right- Since almost all traffic comes from clients which support c-e gzip, intermediaries will not need to decompress the vast majority of the time.

The opposite is true for a-e gzip, unfortunately.
Almost no clients support it, thus the intermediary is almost always decompressing, and it also thus has poor discrimination between malicious and innocent actors. In other words the DoS surface area is very much bigger.

The difference in real behavior is thus large, all due to the fact that c-e gzip has far better support in deployed implementations.

-=R

On May 2, 2014 11:42 AM, <[email-masked]<mailto:[email-masked]>> wrote:
You missed the first sentence of Roberto's statement:
"If compression is per-segment as opposed to per-frame..."

-Keith

On May 2, 2014, at 18:23, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:

cheers,
-johnny

On Fri, May 2, 2014 at 3:54 AM, <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:

---

From: Roberto Peon <[email-masked]>
Date: Fri, 2 May 2014 14:13:02 -0700

On Fri, May 2, 2014 at 1:51 PM, <[email-masked]> 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

---

From: <[email-masked]>
Date: Fri, 2 May 2014 21:49:50 +0000

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, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, May 2, 2014 at 1:51 PM, <[email-masked]<mailto:[email-masked]>> 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

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 2 May 2014 15:02:57 -0700

On Fri, May 2, 2014 at 2:49 PM, <[email-masked]> 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
> 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, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>> wrote:
>
>
>
>
> 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).