Re: [hybi] Restarting IESG review on permessage-deflate

[Peter Thorson <[e-mail]>]

On Oct 4, 2013, at 11:25 , Joakim Erdfelt <[e-mail]> wrote:

> On Fri, Oct 4, 2013 at 8:57 AM, Tobias Oberstein <[e-mail]> wrote:
> The spec use of these prefixes is unclear at best, and downright misleading at worst.
> If the spec is trying to say something like this ...
> 
>    Hi, I'm the client, I want to talk to you using 1 set of configurations, and I want you to talk back to me on a different set of configurations.
> 
> ... then this is not made clear in http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-12 
> 
> And If this is the intention, make it clear, in the spec, that the whole point of the prefixes is to have different configurations for incoming vs outgoing frames. (and explain the pros and cons of this)

Based on my reading of the draft 12 spec sections for the individual method parameters (sec 8.1.1.1-4), it seemed clear to me that the intention is specifically to allow asymmetric configuration.

This is useful because the nature of the deflate algorithm and the capabilities of endpoints are likely to be asymmetric. Deflate typically takes significantly more memory than inflate. Desktop browsers are likely to be less memory sensitive than a server processing tens of thousands of connections each needing their own sliding window or a server running on an embedded device with limited memory. In these cases the resource rich endpoint may want to use its extra memory for a better outgoing compression ratio while allowing the resource poor endpoint to compress less thoroughly to conserve memory.

While I think the present descriptions of each individual parameter convey this information, I wouldn't be opposed to clarifying the overview part of section 8 to review the asymmetric nature of the parameters. A proposal:

======= Existing =======

For an offer for this extension, the following 4 extension parameters
are defined.  If needed to distinguish from ones for a response,
these parameters are called with a prefix "client-to-server".

- "s2c_no_context_takeover"
- "c2s_no_context_takeover"
- "s2c_max_window_bits"
- "c2s_max_window_bits"

For a response for this extension, the following 4 extension
parameters are defined.  If needed to distinguish from ones for an
offer, these parameters are called with a prefix "server-to-client".

- "s2c_no_context_takeover"
- "c2s_no_context_takeover"
- "s2c_max_window_bits"
- "c2s_max_window_bits"

======= Possible clarification =======

Four extension parameters are defined for permessage-deflate to help 
endpoints manage per-connection resource usage.

- "s2c_no_context_takeover"
- "c2s_no_context_takeover"
- "s2c_max_window_bits"
- "c2s_max_window_bits"

These represent two methods of constraining memory usage that may be 
applied independently to either direction of WebSocket traffic. The prefixes 
c2s and s2c are used to indicate the client-to-server channel and the 
server-to-client channel respectively. All four parameters are defined for both 
a client's offer and a server's response.

=====================

> - Joakim
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi