Re: Questions on Frame Size

David Morris <dwm@xpasc.com> Fri, 21 June 2013 01:16 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 AF2E321F9A8B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Jun 2013 18:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.161
X-Spam-Level:
X-Spam-Status: No, score=-8.161 tagged_above=-999 required=5 tests=[AWL=2.438, 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 K1ktSpwS0EOG for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 20 Jun 2013 18:16:27 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D4E5921F99D9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 20 Jun 2013 18:16:26 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uppx2-0006TR-Hv for ietf-http-wg-dist@listhub.w3.org; Fri, 21 Jun 2013 01:15:44 +0000
Resent-Date: Fri, 21 Jun 2013 01:15:44 +0000
Resent-Message-Id: <E1Uppx2-0006TR-Hv@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <dwm@xpasc.com>) id 1Uppwh-0006Se-2L for ietf-http-wg@listhub.w3.org; Fri, 21 Jun 2013 01:15:23 +0000
Received: from c2w3p-2.abacamail.com ([209.133.53.32]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <dwm@xpasc.com>) id 1Uppwg-00064X-Fx for ietf-http-wg@w3.org; Fri, 21 Jun 2013 01:15:23 +0000
Received: from xpasc.com (h-68-164-244-188.snva.ca.megapath.net [68.164.244.188]) by c2w3p-2.abacamail.com (Postfix) with ESMTP id 6508D3F708 for <ietf-http-wg@w3.org>; Fri, 21 Jun 2013 01:14:55 +0000 (UTC)
Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id r5L1Esk5022939 for <ietf-http-wg@w3.org>; Thu, 20 Jun 2013 18:14:54 -0700
Date: Thu, 20 Jun 2013 18:14:54 -0700
From: David Morris <dwm@xpasc.com>
Reply-To: 'HTTP Working Group' <ietf-http-wg@w3.org>
cc: 'HTTP Working Group' <ietf-http-wg@w3.org>
In-Reply-To: <51C3A2A4.6030601@treenet.co.nz>
Message-ID: <alpine.LRH.2.01.1306201809370.21683@egate.xpasc.com>
References: <51C293FD.1040806@iij.ad.jp> <CABP7RbeS7zeVnOM7R0mcUe+t-M+Ta3GVZr+1A3gSjY8QqCOgzQ@mail.gmail.com> <51C3823E.7010706@iij.ad.jp> <51C3A2A4.6030601@treenet.co.nz>
User-Agent: Alpine 2.01 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Milter-Version: master.87-g7939dec
X-AV-Type: clean
X-AV-Accuracy: exact
Received-SPF: pass client-ip=209.133.53.32; envelope-from=dwm@xpasc.com; helo=c2w3p-2.abacamail.com
X-W3C-Hub-Spam-Status: No, score=-2.7
X-W3C-Hub-Spam-Report: AWL=-3.883, MISSING_HEADERS=1.207, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1Uppwg-00064X-Fx ea0cff4655ba68925ca663ae87978dcf
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Questions on Frame Size
Archived-At: <http://www.w3.org/mid/alpine.LRH.2.01.1306201809370.21683@egate.xpasc.com>
To: ietf-http-wg@w3.org
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18330
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>

On Fri, 21 Jun 2013, Amos Jeffries wrote:
 
> Which implies that server-push is a different protocol to HTTP already.

Different from 1.1, but a new feature of 2.0

 
> IIRC: the 64K limit is for next-generation requirements of systems running
> HTTP at TB speeds. Allowing new frames to be added for those larger line rates
> is very useful given they are already on the horizon and HTTP/2.0 has long
> lifetime ahead.

In the SF Interim, we agreed to 64K/16K (frame/vs HTTP) to allow for the 
larger frame required to establish a TLS connection without added round
trips because the initial TLS setup exceeded a single frame.