Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits

"Adrien W. de Croy" <adrien@qbik.com> Tue, 28 May 2013 22:52 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE9B21F907E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 15:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biciuN68ySHg for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 15:52:15 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 85D3221F9058 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 May 2013 15:52:15 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UhSjE-00028q-IW for ietf-http-wg-dist@listhub.w3.org; Tue, 28 May 2013 22:50:52 +0000
Resent-Date: Tue, 28 May 2013 22:50:52 +0000
Resent-Message-Id: <E1UhSjE-00028q-IW@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1UhSiz-00026Z-Ga for ietf-http-wg@listhub.w3.org; Tue, 28 May 2013 22:50:37 +0000
Received: from smtp.qbik.com ([210.55.214.35]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1UhSis-0005o8-PH; Tue, 28 May 2013 22:50:36 +0000
Received: From SCREECH.qbik.local (unverified [192.168.0.4]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 4556)) with SMTP id <0019740393@smtp.qbik.com>; Wed, 29 May 2013 10:50:02 +1200
Received: From [192.168.0.23] (unverified [192.168.0.23]) by SMTP Server [192.168.0.4] (WinGate SMTP Receiver v8.0.0 (Build 4555)) with SMTP id <0000213832@SCREECH.qbik.local>; Wed, 29 May 2013 10:50:01 +1200
From: "Adrien W. de Croy" <adrien@qbik.com>
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Date: Tue, 28 May 2013 22:50:01 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8
In-Reply-To: <alpine.LRH.2.01.1305281410440.10135@egate.xpasc.com>
Message-Id: <em5d1e5e34-4488-4104-a575-5e400de51493@bodybag>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <adrien@qbik.com>
User-Agent: eM_Client/5.0.18025.0
Received-SPF: pass client-ip=210.55.214.35; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-2.871, RP_MATCHES_RCVD=-1.07, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UhSis-0005o8-PH e568689a0332f072a85e351adc3f50d8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
Archived-At: <http://www.w3.org/mid/em5d1e5e34-4488-4104-a575-5e400de51493@bodybag>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18128
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

my vote would be to leave it at 16 bits, and actually allow for some 
mechanism to raise it (we don't know what transports we may be able to 
use in future that make 64kB seem too small).

HOL blocking of frames is only one issue.  If a server has to support 
multiple streams it can scale back the frames it sends to achieve better 
responsiveness.  It has that choice.

But there are plenty of single stream bulk transfers out there that 
would not thank you for limiting frame size to say 4kb and increasing 
their workload.

It's not just filling the wire and wire-efficiency and wire overhead.  
Each frame takes a certain amount of processing overhead.  You quadruple 
the number of frames to send 64kB and you quadruple if not more the 
amount of CPU resource taken to process the frames.

So IMO it makes no sense to chisel into stone 12bits in the protocol.


------ Original Message ------
From: "David Morris" <dwm@xpasc.com>
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Sent: 29/05/2013 9:14:40 a.m.
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
>
>
>On Tue, 28 May 2013, Patrick McManus wrote:
>
>>  On Tue, May 28, 2013 at 4:12 PM, Roberto Peon <grmocg@gmail.com> 
>>wrote:
>>
>>  My sweet-spot number was 16k, as I knew that I could saturate a 10G 
>>nic
>>  > with 16k frames/writes and have enough CPU left over to do some 
>>actual
>>  > work. The amount of overhead goes up more than linearly with the 
>>decrease
>>  > in frame size thanks to contention, etc.
>>  >
>>  >
>>
>>  Given what you've said here and in the other mail (plus of course my 
>>own
>>  previously stated concerns) I'm inclined to suggest a 16KB max (14 
>>bits)
>>  without introducing any kind of max frame size configurable. My point 
>>is to
>>  drive it as small as we can without creating excessive overhead and 
>>you've
>>  put a stake in the ground that 16KB is that level. That's still 4x as
>>  aggressive as the current draft.
>
>I've been working with a product for a number of years which 
>incorporates
>muxed http response streams where 16k chunks per streams seem to work
>well. Our design concern was to keep low speed connections full while
>minimizing HOL blocking. Unfortunately, there is no easy way to test
>alternatives.
>