Re: HTTP router point-of-view concerns

Amos Jeffries <> Fri, 12 July 2013 08:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF6D921F9D45 for <>; Fri, 12 Jul 2013 01:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.556
X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YlE5A6sOQW-U for <>; Fri, 12 Jul 2013 01:28:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6B0A221F9D46 for <>; Fri, 12 Jul 2013 01:28:08 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UxYgv-0000cn-4B for; Fri, 12 Jul 2013 08:27:01 +0000
Resent-Date: Fri, 12 Jul 2013 08:27:01 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UxYgj-0000Yj-QX for; Fri, 12 Jul 2013 08:26:49 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1UxYgi-0005vM-TH for; Fri, 12 Jul 2013 08:26:49 +0000
Received: from [] ( []) by (Postfix) with ESMTP id D15FEE6F4B for <>; Fri, 12 Jul 2013 20:26:24 +1200 (NZST)
Message-ID: <>
Date: Fri, 12 Jul 2013 20:26:19 +1200
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.449, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UxYgi-0005vM-TH 2767a27454b704041b9b2c5ee8c45913
Subject: Re: HTTP router point-of-view concerns
Archived-At: <>
X-Mailing-List: <> archive/latest/18717
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 12/07/2013 7:35 a.m., Roberto Peon wrote:
> I think it is perfectly reasonable for an intermediary to set the 
> compression size to zero if it wishes.
> Market forces will (in the long-term) pick the correct strategy for 
> this-- assuming the compression is effective at reducing latency, and 
> that people care about latency reductions, then eventually 
> intermediaries might evolve to use it.
> If it is ineffective at reducing latency, or if reduced latency is not 
> actually desirable, then intermediaries would not use it.
> The DoS vector you're talking about is not a DoS vector if the 
> intermediary resets all streams before the change-of-state-size comes 
> into effect.

If you means RST_STREAM on all the initial streams which use a larger 
compression size then what you are doing is adding an RTT penalty to all 
those requests over and beyond what HTTP/1 suffers from already on a 
normal transaction. This is not a useful way forward (wastes packets, 
RTT and stream IDs) and resolving it is to make decompression with the 
default state size mandatory for all recipients. Which brings us full 
circle on the problem of having a default >0 in the dynamic part of the 
state tables.

> When the state size is 0, one should be able to use some kinds of 
> 'indexed' representations, so long as those representations refer only 
> to items in the static tables. Why do you believe that this would use 
> more or less CPU? (It should use less CPU and less memory...)

I did not mention CPU. Only the bandwidth amplification effects that 
agents disabling compression would incur and need to consider carefully.

Personally I would like to see a 127 entry mandatory static table in the 
spec itself and tied to the "2.0" version with a 127 entry optional 
dynamic table indicated by the high-end bit of the byte code. With a 
capacity byte size for dynamic table sent each way and senders forbidden 
to add new entries to the dynamic table until they hold the value from 
both ends of the connection. Agreed value being the minimum of both ends