Subject: [hybi] working group last call on draft-ietf-hybi-permessage-compression-04 (until November 14th)

From: Salvatore Loreto <[email-masked]>
Date: Tue, 23 Oct 2012 14:59:39 +0300

Hi there,

this message initiates a three-weeks working group last call (WG LC) on 
draft-ietf-hybi-permessage-compression-04
to be completed on November 14th:

http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-04

At this point, we haven't seen any objection on the core design of this 
extension for quite long,
all the feedback/clarification-requests raised in the mailing list have 
been addressed by the Takeshi.

Note: to clarify to those not so familiar with the IETF process, a WG LC 
is a final check within the working group to prepare a draft
to be ready for subsequent submission to the IESG

Thanks,
Gabriel and Salvatore

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 31 Oct 2012 20:54:15 +0200

just a reminder!

  WGLC for the draft-ietf-hybi-permessage-compression-04 is on going.

So please, read and review the draft and send to the mailing list
all your technical and/or editorial comments, concerns and feedback in 
general you have.

thanks
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

On 10/23/12 2:59 PM, Salvatore Loreto wrote:
> Hi there,
>
> this message initiates a three-weeks working group last call (WG LC) 
> on draft-ietf-hybi-permessage-compression-04
> At this point, we haven't seen any objection on the core design of 
> this extension for quite long,
> all the feedback/clarification-requests raised in the mailing list 
> have been addressed by the Takeshi.
>
>
> Note: to clarify to those not so familiar with the IETF process, a WG 
> LC is a final check within the working group to prepare a draft
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Peter Thorson <[email-masked]>
Date: Wed, 31 Oct 2012 16:49:11 -0500

Hi All,

I've been working on implementing permessage-compress the past week as an aid to reviewing the extension. It is not complete yet, but I have a few notes so far and a question.

First a question: are there any existing implementations of permessage-compress (either client or server) suitable for me to test interoperability with?

*Feedback on permessage-compress*

Regarding Extension Negotiation
Section 3. Extension Negotiation describes the grammar of the list of compression method descriptions. It references `token` in the ABNF. Is token universally defined in ABNF? Or does token here refer to the definition of token from RFC2616(HTTP 1.1)? In RFC6455 (Websocket Protocol), which also uses RFC2616 tokens explicitly mentions this and cites RFC2616 for the definition of token.

If indeed the token syntax from HTTP 1.1 is intended it might be worth citing either RFC6455 or RFC2616 as the source for the `token` ABNF.

Overall, this section is largely similar to section 9.1 (Extension Negotiation) of RFC6455 except with less detail (specifically: no mention of the borrowed HTTP 1.1 semantics including critical reminders of things like the implied *LWS rules). If each extension is going to include the exact details of extension negotiation I'd suggest that it include all of this language. Alternatively, a much simpler description of extension negotiation that refers the reader to RFC6455 section 9.1 for the details might be appropriate.

Some minor english issues:

Abstract:
Current: It compresses the payload of non-control WebSocket messages using specified compression algorithm.
Potential correction: It compresses the payload of non-control WebSocket messages using a specified compression algorithm.

Introduction:
Current: This extension negotiates what compression method to use on opening handshake, ...
Potential correction: This extension negotiates what compression method to use during the opening handshake, ...

*Some observations from my work implementing this extension*

This is not really related to this extension specifically, but rather an observation about the negotiation system already specified in RFC6455 that can be ignored until attempting to support an extension for the first time. The use of the full HTTP 1.1 header field data list syntax adds considerable complexity for any implementation that doesn't already have access to a mature HTTP header parsing library. WebSocket implementations sans extensions can get by with drastically simplified header parsing logic (for better or for worse). The introduction of extensions with complex negotiation parameters requires a more complete header parsing system. I suspect this will be an area in need of careful testing and defenses against incomplete implementations.

The introduction of compression introduces a number of issues that should be taken into account, especially for low level/embedded users and servers needing very high numbers of concurrent connections. These aren't criticisms or even specific to permessage-compress, just observations that other implementations might find useful and are different than the compression issues typically found in traditional HTTP servers.
- Additional buffering and copying can result in lower performance than you might expect from just the additional compression work
- Compression breaks a number of optimizations that servers can use to reduce CPU and memory usage like outgoing message preparation/de-duplication.
- Compression drastically increases per connection memory usage. This can be mitigated somewhat at a compression efficiency loss via the window bits and context takeover parameters, but it requires adequate library support and in some cases cooperation of the remote endpoint. 

Whether compression makes sense or with what settings does it make sense will depend highly on expected workload, one size fits all defaults may not be effective. Documentation should make it clear that there are non-trivial tradeoffs to enabling compression for certain workloads (especially high concurrency short message ones). Servers and libraries especially may need to provide options and documentation to allow users to tune resource usage based on their expected workloads.

best,

Peter Thorson

On Oct 31, 2012, at 13:54 , Salvatore Loreto <[email-masked]> wrote:

> all your technical and/or editorial comments, concerns and feedback in general you have.
> 
> 
> 
> thanks
> Salvatore
> 
> -- 
> Salvatore Loreto, PhD
> www.sloreto.com
> 
> 
> 
>> this message initiates a three-weeks working group last call (WG LC) on draft-ietf-hybi-permessage-compression-04
>> At this point, we haven't seen any objection on the core design of this extension for quite long,
>> all the feedback/clarification-requests raised in the mailing list have been addressed by the Takeshi.
>> 
>> 
>> Note: to clarify to those not so familiar with the IETF process, a WG LC is a final check within the working group to prepare a draft