IETF Logo Mail Archive

Questions on Frame Size

Shigeki Ohtsu <ohtsu@iij.ad.jp> Thu, 20 June 2013 05:35 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 0EB5A21E80C3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 19 Jun 2013 22:35:37 -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 pr28L4e6jqfi for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 19 Jun 2013 22:35:32 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF7F21E8056 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 19 Jun 2013 22:35:31 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UpXV2-00056u-IL for ietf-http-wg-dist@listhub.w3.org; Thu, 20 Jun 2013 05:33:36 +0000
Resent-Date: Thu, 20 Jun 2013 05:33:36 +0000
Resent-Message-Id: <E1UpXV2-00056u-IL@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ohtsu@iij.ad.jp>) id 1UpXUi-00055O-Td for ietf-http-wg@listhub.w3.org; Thu, 20 Jun 2013 05:33:16 +0000
Received: from mo30.iij.ad.jp ([202.232.30.71] helo=omgo.iij.ad.jp) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ohtsu@iij.ad.jp>) id 1UpXUe-00059D-Od for ietf-http-wg@w3.org; Thu, 20 Jun 2013 05:33:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iij.ad.jp; h=Message-ID: Date:From:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; i= ohtsu@iij.ad.jp; s=omgo1; t=1371706369; x=1372915969; bh=DOKa2EmeUn9K76rRps+3ZcTp VTv6N1LKlOXIurbEZUw=; b=ql7SGAbJ2SwMmZ0b1nyNgsz4QD9PvtqRqHXfXto/NPH/nFyM8ZyRHT fOGNnECNyhfJxWJwMW60aGbOH1ZwPcS4uS0YcxM3Ts8oMhD1g3njAsh//NxpdQB+JjHHA26DZ+XLk v8AY74EX/yxz2qosvXUk2yVKvRWdsDqQFOUyey7M=;
Received: by omgo.iij.ad.jp (mo30) id r5K5Wm4s015852; Thu, 20 Jun 2013 14:32:48 +0900
Message-ID: <51C293FD.1040806@iij.ad.jp>
Date: Thu, 20 Jun 2013 14:32:45 +0900
From: Shigeki Ohtsu <ohtsu@iij.ad.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=202.232.30.71; envelope-from=ohtsu@iij.ad.jp; helo=omgo.iij.ad.jp
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: AWL=-2.812, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.276, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UpXUe-00059D-Od 1f68c2031034029b0285cecf9f3c09eb
X-Original-To: ietf-http-wg@w3.org
Subject: Questions on Frame Size
Archived-At: <http://www.w3.org/mid/51C293FD.1040806@iij.ad.jp>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18312
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>

Hi,

The issues about frame size were discussed and might had some
agreements at SF interium but please let me ask some questions on the
current spec of "3.3.2 Frame Size" which is updated by
https://github.com/http2/http2-spec/commit/fd703b572cfc527582c0716e59f2c4044ae195a8

1. "For instance, individual DATA and HEADERS frames used to express
HTTP request and response messages (see Section 4) are not permitted
to exceed 16,383 octets of payload."

PUSH_PROMISE is not listed.
Is the data size of PUSH_PROMISE also limited to 16K or is it exceptional
for some reason?

2. "The absolute maximum amount of payload data any individual frame
 can contain is 65,535 octets. All implementations SHOULD be capable
 of receiving and minimally processing frames up to this size."

If PUSH_PROMISE has a 16K limit, the max frame size is still 64K,
however, any other frames besides DATA, HEADERS and PUSH_PROMISE
are only several octets at most.

Is it for the future extension not to change the frame length to 14bit?
If so, why the spec requires all implementations to support the 64K frame
 size only for the future extension?

Regards,

v2.23.0 | Report a Bug | By Email