Subject: [hybi] permessage-deflate and missing asymmetric configurations

From: Joakim Erdfelt <[email-masked]>
Date: Wed, 9 Oct 2013 11:48:12 -0700

One important aspect missing from the asymmetric configurations for
permessage-deflate is the lack of disabling the compression.

It would be ideal to allow an asymmetric connection where, for example the
client is talking compressed, but the server is not. (or vice versa)

Why is this feature not present in the spec?

--
Joakim Erdfelt <[email-masked]>
webtide.com <http://www.webtide.com/> - intalio.com/jetty
Expert advice, services and support from from the Jetty & CometD experts
eclipse.org/jetty - cometd.org

---

From: Peter Thorson <[email-masked]>
Date: Wed, 9 Oct 2013 14:34:14 -0500

The spec allows disabling compression on a per message basis. To do what you describe a server could simply negotiate compression per the client's request then not send any compressed frames or create any compression contexts for itself.

There may be some additional resource savings possible if an endpoint knows it will never receive a compressed message. That should be considered at least.

On Oct 9, 2013, at 13:48 , Joakim Erdfelt <[email-masked]> wrote:

> One important aspect missing from the asymmetric configurations for permessage-deflate is the lack of disabling the compression.
> 
> It would be ideal to allow an asymmetric connection where, for example the client is talking compressed, but the server is not. (or vice versa)
> 
> webtide.com - intalio.com/jetty
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Joakim Erdfelt <[email-masked]>
Date: Wed, 9 Oct 2013 12:45:31 -0700

Was the idea of having compression level as a configurable ever on the
table?
Then we could simply state a compression level of 0, which would still
create the deflate blocks, but do no real work or effort to compress.

As for having the endpoint code control behavior inside of an extension,
that seems difficult to control or expose.
For example: do we even have the ability, in javascript on the browser, to
control the extensions that are offered? or interrogate the open connection
to know what extensions have been negotiated?

On Wed, Oct 9, 2013 at 12:34 PM, Peter Thorson <[email-masked]>wrote:

> The spec allows disabling compression on a per message basis. To do what
> you describe a server could simply negotiate compression per the client's
> request then not send any compressed frames or create any compression
> contexts for itself.
>
> There may be some additional resource savings possible if an endpoint
> knows it will never receive a compressed message. That should be considered
> at least.
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 10 Oct 2013 05:24:23 +0900

> Was the idea of having compression level as a configurable ever on the

Since each endpoint can choose any compression level as long as wbits and
context mode are negotiated, I didn't include compression level negotiation.

> create the deflate blocks, but do no real work or effort to compress.

IIRC, with only a few people but we reached consensus that we'll start
experimenting heuristics to choose compression on/off in UAs and also
updating API spec to allow webapps to turn on/off compression for each
message.

Adding extension parameters to turn on/off compression allows for disabling
client-to-server compression while enabling server-to-client compression
but it's per-connection level configuration. I was not sure if it's so
worthwhile to include such a halfway feature.

> to know what extensions have been negotiated?

Using the extensions attribute, we can know what extensions are negotiated.

Rough plan was adding some attribute or method or overloading send() method
of WebSocket to allow webapps to flip compression on/off.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 10 Oct 2013 05:35:28 +0900

> knows it will never receive a compressed message. That should be considered

In terms of software without very tight memory limitation, it can be
accomplished just by delaying initialization of inflater until it sees a
compressed message?

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 10 Oct 2013 05:59:18 +0900

If we introduce the feature it'll be like this. We add new parameters, say,
server_no_compress and client_no_compress.

- client MAY request server_no_compress
- client MAY send a hint client_no_compress
- server MAY respond with client_no_compress
- server MUST respond with server_no_compress if received it from client

- client MUST NOT include server_no_compress together with other server_
parameters
- server MUST NOT include server_no_compress together with other server_
parameters
- server MUST NOT include client_no_compress together with other client_
parameters

---

From: Tobias Oberstein <[email-masked]>
Date: Sun, 13 Oct 2013 01:13:18 -0700

>>Was the idea of having compression level as a configurable ever on the table?
>Since each endpoint can choose any compression level as long as wbits and context mode are negotiated, I didn't include compression level negotiation.
 
Exactly.

We only need to negotiate parameters that must be agreed upon make the communication compatible - not every knob that is available at the compressor/decompressor within each endpoint.

Compression level is a useful knob .. but doesn't need to be negotiated.

>Rough plan was adding some attribute or method or overloading send() method of WebSocket to allow webapps to flip compression on/off.

Exposing an API for apps to control compression yes/no on a _per message_ basis is definitely worth: the app might have knowledge whether a given payload is compressible at all. E.g. when the app has encrypted the payload (for end-to-end privacy), it makes no sense to compress at WS level. Payload needs to be compressed before encryption.

/Tobias

---

From: Tobias Oberstein <[email-masked]>
Date: Sun, 13 Oct 2013 01:18:40 -0700

my vote: -1 for those new parameters.

IMHO they are not needed: an endpoint can choose to not compress (an individual or all) messages anyway without any negotiation needed - it can also discard context even when context takeover was negotiated and choose less window bits than negotiated.

In essence, the negotiation only needs to establish _upper bounds_ on resource consumption (memory) within endpoints. Hence, context takeover and window bits.

/Tobias

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Takeshi Yoshino
Gesendet: Mittwoch, 9. Oktober 2013 22:59
An: Joakim Erdfelt
Cc: [email-masked]; Peter Thorson
Betreff: Re: [hybi] permessage-deflate and missing asymmetric configurations

If we introduce the feature it'll be like this. We add new parameters, say, server_no_compress and client_no_compress.

- client MUST NOT include server_no_compress together with other server_ parameters
- server MUST NOT include server_no_compress together with other server_ parameters
- server MUST NOT include client_no_compress together with other client_ parameters