Return-Path: 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 8D65821F86D3 for ; Tue, 28 May 2013 18:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 I3aBD+L3Sd4f for ; Tue, 28 May 2013 18:11:04 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB9521F86CE for ; Tue, 28 May 2013 18:11:04 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1UhUto-0006wK-OO for ietf-http-wg-dist@listhub.w3.org; Wed, 29 May 2013 01:09:56 +0000 Resent-Date: Wed, 29 May 2013 01:09:56 +0000 Resent-Message-Id: Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1UhUta-0006vH-VG for ietf-http-wg@listhub.w3.org; Wed, 29 May 2013 01:09:43 +0000 Received: from mail-oa0-f46.google.com ([209.85.219.46]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1UhUtW-0000X2-04 for ietf-http-wg@w3.org; Wed, 29 May 2013 01:09:42 +0000 Received: by mail-oa0-f46.google.com with SMTP id h2so10923661oag.33 for ; Tue, 28 May 2013 18:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hC9Nw4wyJ2RVVae5NQNBbxumBhQjnHaPgVZU2qDdUe0=; b=qMInnQtz7jZSScJqSub2unKybfbc4DLvcf61MiD50AmoRns3Z4BtYKhBfUY2tH7N89 qFCgdmuFVL0DQdza+Lq0Y/YdK22DL54Uv3X98KMwa/SPIwW4Gw++dHlIZqhXGfmDq4Ln CMESY5XCSgUHt2OMhInxgzDmu1k0UyZ035e2vbWD0634t57c0to2OykVNV9xgx7a/kmw tq3Qgh+v/MT5t8BsVC04T+OQ5mDuT8Bhv2kPaJQuVRUUPFDv5se92tFRUPwm4vBOhqTT KYXOoNdTLq7Hx/k4eXOIKbChxQuuAYNyglMALCDzHT2Zg59MohAARo0C7aksmWLVM46Q dwfg== MIME-Version: 1.0 X-Received: by 10.60.59.163 with SMTP id a3mr259026oer.45.1369789751958; Tue, 28 May 2013 18:09:11 -0700 (PDT) Received: by 10.76.169.68 with HTTP; Tue, 28 May 2013 18:09:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 May 2013 18:09:11 -0700 Message-ID: From: Roberto Peon To: "Adrien W. de Croy" Cc: Patrick McManus , Martin Thomson , HTTP Working Group Content-Type: multipart/alternative; boundary=089e013d081895236c04ddd1071b Received-SPF: pass client-ip=209.85.219.46; envelope-from=grmocg@gmail.com; helo=mail-oa0-f46.google.com X-W3C-Hub-Spam-Status: No, score=-3.5 X-W3C-Hub-Spam-Report: AWL=-2.656, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1UhUtW-0000X2-04 b8e4ae889b22174950316bbeecc83a63 X-Original-To: ietf-http-wg@w3.org Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/18135 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --089e013d081895236c04ddd1071b Content-Type: text/plain; charset=ISO-8859-1 responses inline On Tue, May 28, 2013 at 5:22 PM, Adrien W. de Croy wrote: > > > ------ Original Message ------ > From: "Patrick McManus" > Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits > > > On Tue, May 28, 2013 at 7:19 PM, Adrien W. de Croy wrote: > >> >> >> take a look at any protocol where after a while people decided that the >> size limits were too small. I can think of several off the top of my head: >> DNS, DHCP and BGP >> >> I don't think those are good comparisons here because those protocols > have maximum atomic message sizes of one sort or another, while here we are > discussing the size of the atom in a format that already takes multiple > atoms - not the size of the message. > > > understood. I'm just talking about framing overhead in terms of burden on > CPU and stack. > > Why do we think there are jumbo frames in ethernet? Because 1514 turned > out to be too small in some cases. How widespread are jumbo frames? How > hard is it to deploy something that relies on them? > > I think you make a better argument for getting rid of FRAME_TOO_LARGE. > > FRAME_TOO_LARGE is required if the field width allows a size bigger than > you are willing to accept. So I think it needs to stay. > > > There aren't any streams that can be expressed with 24 bit frame sizes > that can't be with 16, 14, or 12. Its just a matter of various forms of > overhead and responsiveness. > > exactly. And what is the priority problem to solve. > > My point is if we focus too much on HOL blocking of frames, in the context > of > > * today's link technologies > * today's transport layer protocols > * today's requirements (resource sizes etc) > > and use that to set a size limit on a frame by way of field width of the > frame size field, then we will probably create problems down the track > which we could actually avoid now. > > My expectation is that > > * resource sizes will increase over time > * links will get faster > * buffers will get bigger (yes buffer bloat is an issue) and transports > will eventually evolve with larger windows > > > I would be interested in the discussion that led to SPDY being 24 bits. > It was easy. We didn't think about too much and had decided that 24 bits was fairly large. :) We knew that we needed some flags, and decided that doing that byte aligned was the easy thing. Thus, 32 bits of length became 8 bits of flags and 24 bits of length. Later we discovered the problems with implementations in the wild abusing the maximum frame size and screwing up the multiplexing (by using too-large frames which preclude good muxing). > > It's one thing to choose how big a frame to send, it's another to limit it > in protocol. I can choose to send a 4kB frame if the frame size field is > 12, 16, or 32 bits. If you reduce the width though you take away choice. > You're talking about reducing it because you don't like the choices some > people made implementing SPDY. If you're to take away peoples' choice, you > better make the right one for them. > > the spec could allow for bigger frames (as opposed to messages) in the > case where that makes sense, but with caveats about use of sizes. > > If google servers NACKed frames over 4kB, people would stop sending them. > But the agents should maybe know how to and be capable of processing larger > frames. > > > > I brought this to the working group because I believe in running code and > the experience I have gotten here so far tells me most implementations so > far haven't gotten this right. (I've seen at least 3 different one so far > that will write the whole document in 1 frame if they can fit it in spdy's > 24 bits - even though that's just as bad as http/1 pipelines) > > bad or good is from a point of view. The implementors probably thought it > was good. Simplicity can be good. > Then they (implementors who primarily care about simplicity and sacrifice latency to it) should stick with HTTP/1. No joke. If you're not doing multiplexing and prioritization right, you may be better off from a latency perspective using HTTP/1 and sticking to the heuristics. If, because of implementors who've done a poor job, browsers must heuristically delay as they do today, then the entire ecosystem suffers negative latency implications. > > > and a good spec can generate good implementations. Implementation > advice is fine, but its better if it just does the right thing.. and in > this case imo a responsive protocol requires smallish frames. > > I understand and agree that in the cases you're talking about, smallish > frames are good. But there are other cases which we sacrifice for this one > goal that we decide is the most important. On what basis do we decide this > is the most important problem? > > ALPN and Negotiate are not an answer to this. > I believe the intent was to say that this is the first version, and one of the things we're doing is making it substantially easier to rev the protocol. ALPN is the think which makes that easy, and which will thus make this potentially easy. > > What about something like a default max size, so unless something is > advertised, the max is whatever (I'd suggest at least still 16 or 32k, and > the IIS guys might still want 64k). A FRAME_TOO_BIG response if you really > don't want to receive anything bigger, but the field size is 16 and > extensible. So that at any stage implementations have the choice to go > bigger if their application requires it. > > There are many applications other than just serving. > Agreed. I can read and fill a 10G nic at line at 16k frame size with plenty of CPU left over for other things, so I'm not worried about them. :) > For instance something that aggregates messages/frames across some other > network might like to coalesce frames from the same message into larger > ones. You set the size to 12 or even 16 bits and you limit these options > as well. So actually I'd be keen to see 24bits. Costs 1 more byte, but > don't expect to be able to send more than some default value (e.g. 16kB) > without it getting bounced, unless you know you can. > I already know what happens with that frame size-- we get page loads which can actually be slower than that of HTTP/1. > > Adrien > > > > > >> Trying to get widespread deployment of an extension to cope with that is >> an awful mess, and something we shouldn't saddle ourselves with up front. >> >> There are still many DNS implementations that don't understand the size >> extensions. Look at the contortions DHCP took to try to reclaim space. >> >> As for 64kB. Last time I counted TCP stream bytes between PSH flags on >> an HTTP stream from IIS, it was 64kB. I really don't think we should >> reduce it. Servers suffering from HOL issues can always reduce frame size >> themselves for outbound. As for inbound, if there is a settings >> pre-negotiation (which is proposed), why not advertise max frame you will >> accept? >> >> >>> >> >> > --089e013d081895236c04ddd1071b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
responses inline


On Tue, May 28, 2013 at 5:22 PM, Adrien W. de Croy = <= adrien@qbik.com> wrote:
=A0
=A0
------ Original Message ------
From: "Patrick McManus" <mcmanus@ducksong.com>
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits

On Tue, May 28, 2013 at 7:19 PM, Adrien W. de Cr= oy <adrien@qbik.com> wrote:


take a look at any protocol w= here after a while people decided that the size limits were too small. =A0I= can think of several off the top of my head: DNS, DHCP and BGP

I don't think those are good comparisons here because those protoc= ols have maximum atomic message sizes of one sort or another, while here we= are discussing the size of the atom in a format that already takes multipl= e atoms - not the size of the message.
=A0
understood.=A0 I'm just talking about framing overhead in terms of= burden on CPU and stack.
=A0
Why do we think there are jumbo frames in ethernet?=A0 Because 1514 tu= rned out to be too small in some cases.=A0 How widespread are jumbo frames?= =A0 How hard is it to deploy something that relies on them?
I think you make a better argument for getting rid of FRAME_TOO_LARGE.=
FRAME_TOO_LARGE is required if the field width allows a size big= ger than you are willing to accept.=A0 So I think it needs to stay.
=A0
There aren't any streams that can be expressed with 24 bit frame s= izes that can't be with 16, 14, or 12. Its just a matter of various for= ms of overhead and responsiveness.
exactly.=A0And what is the priority problem to solve.
=A0
My point is if we focus too much on HOL blocking of frames, in the con= text of
=A0
* today's link technologies
* today's transport layer protocols
* today's requirements (resource sizes etc)
=A0
and use that to set a size limit on a frame by way of field=A0width of= the frame size field, then we will probably create problems down the track= which we could actually avoid now.
=A0
My expectation is that
=A0
* resource sizes will increase over time
* links will get faster
* buffers will get bigger (yes buffer bloat is an issue) and transport= s will eventually evolve with larger windows
=A0
=A0
I would be interested in the discussion that led to SPDY being 24 bits= .

It was easy. We didn= 9;t think about too much and had decided that 24 bits was fairly large. :) = We knew that we needed some flags, and decided that doing that byte aligned= was the easy thing. Thus, 32 bits of length became 8 bits of flags and 24 = bits of length.
Later we discovered the problems with implementations in the wil= d abusing the maximum frame size and screwing up the multiplexing (by using= too-large frames which preclude good muxing).
=A0
=A0
It's one thing to choose how big a frame to send, it's another= to limit it in protocol.=A0 I can choose to send a 4kB frame if the frame = size field is 12, 16, or 32 bits.=A0 If you reduce the width though you tak= e away choice.=A0 You're talking about reducing it because you don'= t like the choices some people made implementing SPDY.=A0 If you're to = take away peoples' choice, you better make the right one for them.
=A0
the spec could allow for bigger frames (as opposed to messages) in the= case where that makes sense, but with caveats about use of sizes.
=A0
If google servers NACKed frames over 4kB, people would stop sending th= em.=A0 But the agents should maybe know how to and be capable of processing= larger frames.
=A0

I brought this to the working group because I believe in running code = and the experience I have gotten here so far tells me most implementations = so far haven't gotten this right. (I've seen at least 3 different o= ne so far that will write the whole document in 1 frame if they can fit it = in spdy's 24 bits - even though that's just as bad as http/1 pipeli= nes)
bad or good is from a point of view.=A0 The implementors probabl= y thought it was good.=A0 Simplicity can be good.
<= div>
Then they (implementors who primarily care about s= implicity and sacrifice latency to it) should stick with HTTP/1. No joke. I= f you're not doing multiplexing and prioritization right, you may be be= tter off from a latency perspective using HTTP/1 and sticking to the heuris= tics.
If, because of implementors who've done a poor job, browsers= must heuristically delay as they do today, then the entire ecosystem suffe= rs negative latency implications.
=A0
=A0
and a good spec can generate good implementations. Implementation advi= ce is fine, but its better if it just does the right thing.. and in this ca= se imo a responsive protocol requires smallish frames.
I understand and agree that in the cases you're talking abou= t, smallish frames are good.=A0 But there are other cases which we sacrific= e for this one goal that we decide is the most important.=A0 On what basis = do we decide this is the most important problem?
=A0
ALPN and Negotiate are not an answer to this.
=

I believe the intent was to say that this is the = first version, and one of the things we're doing is making it substanti= ally easier to rev the protocol. ALPN is the think which makes that easy, a= nd which will thus make this potentially easy.
=A0
=A0
What about something like a default max size, so unless something is a= dvertised, the max is whatever (I'd suggest at least still 16 or 32k, a= nd the IIS guys might still want 64k).=A0 A FRAME_TOO_BIG response if you r= eally don't want to receive anything bigger, but the field size is 16 a= nd extensible.=A0 So that at any stage implementations have the choice to g= o bigger if their application requires it.
=A0
There are many applications other than just serving.

Agreed. I can read and fill a 10G nic at l= ine at 16k frame size with plenty of CPU left over for other things, so I&#= 39;m not worried about them. =A0:)

=A0
For instance something that aggregates messages/frames across some oth= er network might like to coalesce frames from the same message into larger = ones.=A0 You set the size to 12 or even 16 bits and you limit these options= as well.=A0 So actually I'd be keen to see 24bits.=A0 Costs 1 more byt= e, but don't expect to be able to send more than some default value (e.= g. 16kB) without it getting bounced, unless you know you can.

I already know what happens wi= th that frame size-- we get page loads which can actually be slower than th= at of HTTP/1.
=A0
=A0
=A0Adrien


=A0
Trying to get widespread deployment o= f an extension to cope with that is an awful mess, and something we shouldn= 't saddle ourselves with up front.

There are still many DNS implementations that don't understand the = size extensions. =A0Look at the contortions DHCP took to try to reclaim spa= ce.

As for 64kB. =A0Last time I counted TCP stream bytes between PSH= flags on an HTTP stream from IIS, it was 64kB. =A0I really don't think= we should reduce it. =A0Servers suffering from HOL issues can always reduc= e frame size themselves for outbound. =A0As for inbound, if there is a sett= ings pre-negotiation (which is proposed), why not advertise max frame you w= ill accept?





--089e013d081895236c04ddd1071b--