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 2F60B21E8095 for ; Tue, 28 May 2013 17:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 VrdDBT4sMFjQ for ; Tue, 28 May 2013 17:24:12 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A951311E80A4 for ; Tue, 28 May 2013 17:24:12 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1UhUAr-0008HB-Cx for ietf-http-wg-dist@listhub.w3.org; Wed, 29 May 2013 00:23:29 +0000 Resent-Date: Wed, 29 May 2013 00:23:29 +0000 Resent-Message-Id: Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1UhUAY-0008C8-48 for ietf-http-wg@listhub.w3.org; Wed, 29 May 2013 00:23:10 +0000 Received: from smtp.qbik.com ([210.55.214.35]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1UhUAW-0001cj-Mj for ietf-http-wg@w3.org; Wed, 29 May 2013 00:23:10 +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 <0019740538@smtp.qbik.com>; Wed, 29 May 2013 12:22:41 +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 <0000213889@SCREECH.qbik.local>; Wed, 29 May 2013 12:22:40 +1200 From: "Adrien W. de Croy" To: "Patrick McManus" Cc: "Martin Thomson" , "HTTP Working Group" Date: Wed, 29 May 2013 00:22:39 +0000 Content-Type: multipart/alternative; boundary="------=_MB0082CE2A-36EA-44A8-971B-AD2A24540DB3" In-Reply-To: Message-Id: Mime-Version: 1.0 Reply-To: "Adrien W. de Croy" 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.803, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.07, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1UhUAW-0001cj-Mj 09391f2e9cc5358b119dd3ecb4c22b38 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/18134 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: --------=_MB0082CE2A-36EA-44A8-971B-AD2A24540DB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 ------ 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 =20 >wrote: >> >> >>take a look at any protocol where after a while people decided that=20 >>the size limits were too small. I can think of several off the top of= =20 >>my head: DNS, DHCP and BGP >> >I don't think those are good comparisons here because those protocols=20 >have maximum atomic message sizes of one sort or another, while here we= =20 >are discussing the size of the atom in a format that already takes=20 >multiple atoms - not the size of the message. understood. I'm just talking about framing overhead in terms of burden=20 on CPU and stack. Why do we think there are jumbo frames in ethernet? Because 1514 turned= =20 out to be too small in some cases. How widespread are jumbo frames? =20 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= =20 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=20 >that can't be with 16, 14, or 12. Its just a matter of various forms of= =20 >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=20 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= =20 frame size field, then we will probably create problems down the track=20 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=20 will eventually evolve with larger windows I would be interested in the discussion that led to SPDY being 24 bits. It's one thing to choose how big a frame to send, it's another to limit=20 it in protocol. I can choose to send a 4kB frame if the frame size=20 field is 12, 16, or 32 bits. If you reduce the width though you take=20 away choice. You're talking about reducing it because you don't like=20 the choices some people made implementing SPDY. If you're to take away=20 peoples' choice, you better make the right one for them. the spec could allow for bigger frames (as opposed to messages) in the=20 case where that makes sense, but with caveats about use of sizes. If google servers NACKed frames over 4kB, people would stop sending=20 them. But the agents should maybe know how to and be capable of=20 processing larger frames. > >I brought this to the working group because I believe in running code=20 >and the experience I have gotten here so far tells me most=20 >implementations so far haven't gotten this right. (I've seen at least 3= =20 >different one so far that will write the whole document in 1 frame if=20 >they can fit it in spdy's 24 bits - even though that's just as bad as=20 >http/1 pipelines) bad or good is from a point of view. The implementors probably thought=20 it was good. Simplicity can be good. >and a good spec can generate good implementations. Implementation=20 >advice is fine, but its better if it just does the right thing.. and in= =20 >this case imo a responsive protocol requires smallish frames. I understand and agree that in the cases you're talking about, smallish=20 frames are good. But there are other cases which we sacrifice for this=20 one goal that we decide is the most important. On what basis do we=20 decide this is the most important problem? ALPN and Negotiate are not an answer to this. What about something like a default max size, so unless something is=20 advertised, the max is whatever (I'd suggest at least still 16 or 32k,=20 and the IIS guys might still want 64k). A FRAME_TOO_BIG response if you= =20 really don't want to receive anything bigger, but the field size is 16=20 and extensible. So that at any stage implementations have the choice to= =20 go bigger if their application requires it. There are many applications other than just serving. For instance something that aggregates messages/frames across some other= =20 network might like to coalesce frames from the same message into larger=20 ones. You set the size to 12 or even 16 bits and you limit these=20 options as well. So actually I'd be keen to see 24bits. Costs 1 more=20 byte, but don't expect to be able to send more than some default value=20 (e.g. 16kB) without it getting bounced, unless you know you can. Adrien > > > >>Trying to get widespread deployment of an extension to cope with that=20 >>is an awful mess, and something we shouldn't saddle ourselves with up=20 >>front. >> >>There are still many DNS implementations that don't understand the=20 >>size extensions. Look at the contortions DHCP took to try to reclaim=20 >>space. >> >>As for 64kB. Last time I counted TCP stream bytes between PSH flags=20 >>on an HTTP stream from IIS, it was 64kB. I really don't think we=20 >>should reduce it. Servers suffering from HOL issues can always reduce= =20 >>frame size themselves for outbound. As for inbound, if there is a=20 >>settings pre-negotiation (which is proposed), why not advertise max=20 >>frame you will accept? >> >>> >> >> > --------=_MB0082CE2A-36EA-44A8-971B-AD2A24540DB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
 
 
------ Original Message ------
From: "Patrick McManus" <mc= manus@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 Croy= <adrien@qbik.com= > wrote:


take a look at any prot= ocol 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 multipl= e 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 transport= s will eventually evolve with larger windows
 
 
I would be interested in the discussion that led to SPDY being 24 bits= .
 
It's one thing to choose how big a frame to send, it's another to limi= t 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 proc= essing 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.
 
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= case imo a responsive protocol requires smallish frames.
=
I understand and agree that in the cases you're talking about, smallis= h 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.
 
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.
 
For instance something that aggregates messages/frames across some = other network might like to coalesce frames from the same message into larg= er 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.
 
 Adrien


 
Trying to get widespread deploy= ment 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 accep= t?





--------=_MB0082CE2A-36EA-44A8-971B-AD2A24540DB3--