IETF Logo Mail Archive

[hybi] Payload only compression extension, again

Takeshi Yoshino <tyoshino@google.com> Mon, 28 February 2011 14:50 UTC

Return-Path: <tyoshino@google.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5307B3A6C21 for <hybi@core3.amsl.com>; Mon, 28 Feb 2011 06:50:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.704
X-Spam-Level:
X-Spam-Status: No, score=-105.704 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTr5siFAUhh3 for <hybi@core3.amsl.com>; Mon, 28 Feb 2011 06:50:40 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BC0813A6C1F for <hybi@ietf.org>; Mon, 28 Feb 2011 06:50:39 -0800 (PST)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p1SEpeWx018891 for <hybi@ietf.org>; Mon, 28 Feb 2011 06:51:40 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298904700; bh=N0LUNzkWEzNvKuQeerWWPajJKCc=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=yGHD63c2/+n03seDLY/KaYaDfRdic0vBBE3wLNHs9Az45ntxCCcLqQWXCmJhtqocu agmwhqfsqInTzJF7kAnXQ==
Received: from iyb26 (iyb26.prod.google.com [10.241.49.90]) by wpaz13.hot.corp.google.com with ESMTP id p1SEpcgM003664 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Mon, 28 Feb 2011 06:51:39 -0800
Received: by iyb26 with SMTP id 26so3489873iyb.34 for <hybi@ietf.org>; Mon, 28 Feb 2011 06:51:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=VUcgCC8jG3rpN6KeXfimR3Aw+2HCXfqQCByDAzkMsHM=; b=eQkHP608Bmojk4Dh7vh/oe8HxfcM6+RJErRA1b2ebrA4MGuPuhHWIst78ZEDakc7Jd tnbYsgGTPIOdRL/nwvag==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; b=JNEXzOlf+zJIBlGoth3I9Z4187r0dOPBbF4WSWd9ghOhrl7onWpoL8xXd52jZg0o/Z Leqvbaft9KJ2hH80ftGw==
Received: by 10.231.185.30 with SMTP id cm30mr2217360ibb.59.1298904698233; Mon, 28 Feb 2011 06:51:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.17.201 with HTTP; Mon, 28 Feb 2011 06:51:18 -0800 (PST)
From: Takeshi Yoshino <tyoshino@google.com>
Date: Mon, 28 Feb 2011 23:51:18 +0900
Message-ID: <AANLkTik2LqCC2-ZLLdWNNaQ18ypcQU_5djJobkYtYk6T@mail.gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="00504501740022a474049d58d125"
X-System-Of-Record: true
Subject: [hybi] Payload only compression extension, again
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Feb 2011 14:50:42 -0000

Hi,

Seeing several people preferring payload only compression, I'd like to
resume discussion on it.

Here's requirements and my strawman proposal based on Patrick's proposals
and recent discussion.

I've removed compression indication that might be implemented by some
reserved bits or opcode for now. Please use this as starting point and
propose any extension to add necessary features. Different from the time
deflate-stream was defined, now extension negotiation is well defined in the
spec.

----

Requirements
- Each message must be able to be uncompressed immediately
-- Use Z_SYNC_FLUSH or Z_FINISH at the end of application data
- Want to maintain the compression state (LZ77 sliding window) between
frames
-- Use Z_SYNC_FLUSH
- 4 octet overhead of Z_SYNC_FLUSH is too big
-- Use the same scheme as RFC 1979 PPP Deflate to eliminate it
- Want not to mess up dictionary by compressing incompressible messages
-- Use BTYPE=0b00 block for such messages

Requests I gave up to address in the strawman below for simplicity
- Want to maintain the compression state (LZ77 sliding window and Huffman
table)
- Want to keep separate dictionaries for messages with different
characteristics
-- Case 1: Binary and text mixed
-- Case 2: Short and long mixed
-- Case 3: Application data in data frame and control frame may have
different characteristics
--- Apply DEFLATE only to data frame (Is it worth including control frame?)
- Want to turn off compression for messages that becomes bigger when
compressed e.g. 1-octet message

----

Proposal

Compression

The registered extension token for this compression extension
is "deflate-application-data".

The extension does not have any per message extension data and it does not
define the use of any WebSocket reserved bits or opcodes.

Senders using this extension MUST apply RFC 1951 DEFLATE to all the bytes of
the application data portion of data frames. Senders MAY include multiple
blocks in a frame. Senders MAY use blocks of any type as defined in RFC
1951. Senders MUST use the algorithm described in Section 2.1 of RFC1979 to
align compressed data to byte boundary. Senders MAY keep using the same LZ77
sliding window for multiple frames.

Receivers MUST append 0x00 0x00 0xff 0xff to the application data portion
and decompress it using DEFLATE to decode the original application data.
Receivers MUST keep using the same LZ77 sliding window for all the frames of
the same WebSocket connection. Receivers MUST assume the senders use 32768
byte LZ77 sliding window.

v2.23.0 | Report a Bug | By Email