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

From: Patrick McManus <[email-masked]>
Date: Tue, 28 May 2013 10:20:11 -0400

Hi All,

I've been looking at a lot of spdy frames lately, and I've noticed what I
consider a common implementation problem that I think a good http/2 spec
could help with. I'm commonly seeing frames large enough to interfere with
effective prioritization. I've seen this from at least 3 different servers.

The HTTP/2 draft has a max frame size of 16 bits, which is a huge
improvement from spdy's 24. I propose we reduce it further to 12. (i.e.
4096 bytes).

The muxxed approach of multiple streams onto one connection done in HTTP/2
has great advantages, but the one downside of it is that it creates head of
line blocking problems between those streams dictated by frame granularity.
With small frames this is pretty manageable, with extremely large ones
we've recreated the same head of line problems that HTTP/1 pipelines have.
The server needs to  be able to respond quickly to higher priority events
(including cancellations) and once it has written a frame header to the
wire it is committed to the entire frame for how ever long it takes to
serialize it. IMO the shorter that time, the better.

Our spec can help implementations do the right thing here by limiting the
max frame size to 12 bits.

It takes 500msec to serialize 64KB at 1Mbit/sec... 125msec at 4Mbit/sec.
Those are some pretty notable task-switch times. Dropping the frame to 4096
cuts them to 32msec and 8 msec.. that's much more responsive, at the cost
of 120 extra bytes of transfer (< 1msec at 1Mbit/sec).

In general - the smaller the better as long as the overhead doesn't get to
be too large. At 8 in 4096 (~.2%) I think that's acceptable. Its roughly
the same overhead as a VLAN tag.

Obviously this makes a continuation bit for control frames absolutely
mandatory, but I think we're already in that spot with 16 bit frame lengths.

-Patrick

---

From: James M Snell <[email-masked]>
Date: Tue, 28 May 2013 09:22:41 -0700

Currently, my only challenge with this is that, so far, we have not
seen any documented performance metrics for non-browser based uses.
.That said, I don't really have the time currently to put together a
comprehensive set of such metrics so it wouldn't be polite of me to
insist on them ;-) ... perhaps for now we ought to keep the 16-bit
size but include a recommendation about not exceeding 12-bits, then
see what more implementation experience does for us.

On Tue, May 28, 2013 at 7:20 AM, Patrick McManus <[email-masked]> wrote:
> improvement from spdy's 24. I propose we reduce it further to 12. (i.e. 4096
> bytes).
>
> With small frames this is pretty manageable, with extremely large ones we've
> recreated the same head of line problems that HTTP/1 pipelines have. The
> server needs to  be able to respond quickly to higher priority events
> (including cancellations) and once it has written a frame header to the wire
> it is committed to the entire frame for how ever long it takes to serialize
> it. IMO the shorter that time, the better.
>
> cuts them to 32msec and 8 msec.. that's much more responsive, at the cost of
> 120 extra bytes of transfer (< 1msec at 1Mbit/sec).
>
> be too large. At 8 in 4096 (~.2%) I think that's acceptable. Its roughly the
> same overhead as a VLAN tag.
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 28 May 2013 09:58:18 -0700

Can you clarify what you mean by a documented performance metric for
non-browser use cases? I don't think Patrick said anything browser
specific. He provided some serialization latency numbers and noted that
they are high enough to impact responsiveness. And then he provided numbers
on overhead.

I, for one, find the responsiveness argument compelling for browsers. I'm
not completely sure 0.2% is low enough overhead for everyone, but I
wouldn't complain about it. And in absence of complaints, I guess I'd
support moving forward with only 12 bits for length.

On Tue, May 28, 2013 at 9:22 AM, James M Snell <[email-masked]> wrote:

> 4096
> we've
> wire

---

From: Roberto Peon <[email-masked]>
Date: Tue, 28 May 2013 11:41:52 -0700

As a reverse proxy, I've seen properties for which 4k writes/reads were too
small and induced latency increases.

Admittedly, frame size doesn't have to be the same as read/write size, but
it certainly does encourage that implementation (which is, I think, the
point of smaller max frame size that you proposed).

I propose we keep the 16 bit frame size and instead allow the (now
negotiated setting of) max frame size to default to 12 bits worth, with
that going upwards out downwards when a settings frame arrives from the
other side indicating it's max receive size. HK

This would give the best chance that the code would be written in such a
way as to adapt with the times as they change.
-=R
On May 28, 2013 10:01 AM, "William Chan (陈智昌)" <[email-masked]>

---

From: James M Snell <[email-masked]>
Date: Tue, 28 May 2013 11:50:04 -0700

> small and induced latency increases.

I haven't played with this part too much yet but this is my general
suspicion also.

> negotiated setting of) max frame size to default to 12 bits worth, with that
> going upwards out downwards when a settings frame arrives from the other
> side indicating it's max receive size. HK
>

Honestly, I'd prefer to do away with frame size negotiation altogether
because of the potential for path mtu style issues. Keeping the 16-bit
size for now with strong encouragement (SHOULD, perhaps?) for keeping
sizes around 12-bit lengths for the most common cases  seems like the
right approach.

-- James

> This would give the best chance that the code would be written in such a way
> as to adapt with the times as they change.
> -=R
>
>> non-browser use cases? I don't think Patrick said anything browser specific.
>> He provided some serialization latency numbers and noted that they are high
>> enough to impact responsiveness. And then he provided numbers on overhead.
>>
>> not completely sure 0.2% is low enough overhead for everyone, but I wouldn't
>> complain about it. And in absence of complaints, I guess I'd support moving
>> forward with only 12 bits for length.
>>
>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 28 May 2013 12:16:52 -0700

> I haven't played with this part too much yet but this is my general

Can you guys clarify this in more detail? Specifically, where the latency
comes from. I have ideas, but I'd rather than an authoritative explanation.

> > point of smaller max frame size that you proposed).

You're right that it does encourage that implementation. Just like a larger
length encourages just naively breaking up frames into that max frame size
and thus hurt responsiveness. Which one is likelier to cause worse overall
"performance" (I know this is vague, since people care about different
aspects of perf)? What we want to do is have the most reasonable default
behavior, with the ability for performant implementations to tune without
unreasonable difficulty. I believe we're mostly focusing here on optimizing
the naive implementations, not the highly tuned implementations.

> that
> way
> specific.
> wouldn't
> >>> On Tue, May 28, 2013 at 7:20 AM, Patrick McManus <[email-masked]
> >
> >>> wrote:
> >>> > Hi All,
> >>> >
> >>> > I've been looking at a lot of spdy frames lately, and I've noticed
> what
> >>> > I
> >>> > Those are some pretty notable task-switch times. Dropping the frame
> to
> >>> > 4096
> >>> > In general - the smaller the better as long as the overhead doesn't
> get
> >>> > to

---

From: Roberto Peon <[email-masked]>
Date: Tue, 28 May 2013 13:12:53 -0700

responses inline

> comes from. I have ideas, but I'd rather than an authoritative explanation.

It always comes down to the cost of the context switches (i.e. syscalls)
and the locking that must be done in the lower layers of the IO stack.

> You're right that it does encourage that implementation. Just like a
> larger length encourages just naively breaking up frames into that max
> frame size and thus hurt responsiveness. Which one is likelier to cause
> worse overall "performance" (I know this is vague, since people care about
> different aspects of perf)? What we want to do is have the most reasonable
> default behavior, with the ability for performant implementations to tune
> without unreasonable difficulty. I believe we're mostly focusing here on
> optimizing the naive implementations, not the highly tuned implementations.
>

Remember that I'm the one who proposed the smaller max frame size in the
first place (now a fair while ago)? :)
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.

>> sizes around 12-bit lengths for the most common cases  seems like the
Unlike TCP/IP, max frame size is a point-to-point thing, as the primitive
we mux is streams, not frames. Frames are the way we accomplish the muxing.
Why would there be any path MTU like thing?

-=R

>> >>> On Tue, May 28, 2013 at 7:20 AM, Patrick McManus <
>> [email-masked]>
>> >>> wrote:
>> >>> > Hi All,
>> >>> >
>> >>> > could help with. I'm commonly seeing frames large enough to
>> interfere
>> >>> > with
>> >>> > Our spec can help implementations do the right thing here by
>> limiting
>> >>> > the

---

From: Patrick McManus <[email-masked]>
Date: Tue, 28 May 2013 16:33:29 -0400

On Tue, May 28, 2013 at 4:12 PM, Roberto Peon <[email-masked]> wrote:

> 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.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 28 May 2013 13:36:54 -0700

That is fine by me so long as we mark the rest of the length field as
reserved and don't touch it.
-=R

---

From: David Morris <[email-masked]>
Date: Tue, 28 May 2013 14:14:40 -0700 (PDT)

> 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.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 28 May 2013 22:50:01 +0000

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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 May 2013 16:11:01 -0700

On 28 May 2013 15:50, Adrien W. de Croy <[email-masked]> wrote:
> it makes no sense to chisel into stone 12bits in the protocol.

Not to pick on Adrien, but this isn't stone.

Say we do go with 12 bits.  That doesn't prevent a future extension to
the protocol that enabled the negotiation of larger frame sizes.  It
doesn't prevent the use of a new protocol that had 37bits dedicated to
frame sizes.  The only cost is period of suffering where the 12 bit is
the effective limit until various affected parties move to 37.

Fact is, none of resembles stone on anything but the shortest of
timescales.  You might (reasonably) say that the cost of suffering
times the duration of suffering is excessive, but then you have to
make that case.  Impress upon us the magnitude of that pain, and/or
provide reasoning for why that pain would be prolonged.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 28 May 2013 23:19:05 +0000

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 29/05/2013 11:11:01 a.m.
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
>the effective limit until various affected parties move to 37.
IME this simply doesn't happen.  Look at DHCP and/or DNS if you want an 
example.

We're talking about making the field size in the definition of the frame 
header be 12 bits long.

If that isn't setting it in stone I don't know what is.

>timescales.
are you a geologist? :)

>You might (reasonably) say that the cost of suffering

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

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?

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 May 2013 16:23:39 -0700

On 28 May 2013 16:19, Adrien W. de Croy <[email-masked]> wrote:
> take a look at any protocol where after a while people decided that the size
> limits were too small.

One of these things is not like the others.  We've a clear path for
negotiating upwards.  ALPN and Upgrade both.  (There are also
in-protocol mechanisms possible, at the cost of some extra latency
before the increased size can be used.)

If you believe this to be a real, immediate problem, then I'm sure
that it wouldn't be hard to find material support for your belief
sufficient to convince the rest of the working group.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 28 May 2013 16:25:39 -0700

Just to be clear, I don't feel too strongly here. I do want to address a
point as I feel my previous point was lost.

On Tue, May 28, 2013 at 1:12 PM, Roberto Peon <[email-masked]> wrote:

> responses inline
>
>
> On Tue, May 28, 2013 at 12:16 PM, William Chan (陈智昌) <
> [email-masked]> wrote:
>
>> On Tue, May 28, 2013 at 11:50 AM, James M Snell <[email-masked]>wrote:
>>

Thanks for the clarification, I suspected it was the write()/read() cost,
which I assume is what you mean by syscall.

> first place (now a fair while ago)? :)

I don't believe I've said anything that would imply I forgot that :)

> in frame size thanks to contention, etc.

I think you miss my point. Please correct me if I'm wrong, but I think
you're saying that for your server, 16k was the right choice for write()s.
write() sizes don't need to be tied to actual frame size, but of course
that's what a naive implementation would do. And again, I think we should
pick a max frame size that results in reasonable behavior for naive
implementations/deployments. And I think the highly performant
implementations will want to write their code in a way that decouples frame
size from write() size, and will pick the optimal write() size given the
tradeoffs.

>>> >>> > recreated the same head of line problems that HTTP/1 pipelines
>>> have.
>>> >>> > The
>>> >>> > Those are some pretty notable task-switch times. Dropping the
>>> frame to
>>> >>> > 4096
>>> >>> > cuts them to 32msec and 8 msec.. that's much more responsive, at
>>> the
>>> >>> > cost of
>>> >>> > In general - the smaller the better as long as the overhead
>>> doesn't get
>>> >>> > to

---

From: Patrick McManus <[email-masked]>
Date: Tue, 28 May 2013 19:59:18 -0400

On Tue, May 28, 2013 at 7:19 PM, Adrien W. de Croy <[email-masked]> wrote:

> 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. I think you make a better argument for
getting rid of FRAME_TOO_LARGE. 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.

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) 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.

> an awful mess, and something we shouldn't saddle ourselves with up front.
>
> 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?
>
>
>>
>
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 29 May 2013 00:22:39 +0000

------ Original Message ------
From: "Patrick McManus" <[email-masked]>
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
>>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'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.

>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.

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 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.

  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?
>>
>>>
>>
>>
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 28 May 2013 18:09:11 -0700

responses inline

On Tue, May 28, 2013 at 5:22 PM, Adrien W. de Croy <[email-masked]> wrote:

>  On Tue, May 28, 2013 at 7:19 PM, Adrien W. de Croy <[email-masked]>wrote:
>
>>
>>
> have maximum atomic message sizes of one sort or another, while here we are
> atoms - not the size of the message.
>
>
> understood.  I'm just talking about framing overhead in terms of burden on
> CPU and stack.
>
> out to be too small in some cases.  How widespread are jumbo frames?  How
> hard is it to deploy something that relies on them?
>
> My point is if we focus too much on HOL blocking of frames, in the context
> of
>

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.
>
> 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.
>
>
>
> 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.

> 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?
>

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.

> 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.
>

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.  :)

> 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.

>> reduce it.  Servers suffering from HOL issues can always reduce frame size

---

From: Roberto Peon <[email-masked]>
Date: Tue, 28 May 2013 18:12:57 -0700

I understand what you're saying. We're all agreeing that the max frame size
should be limited. I'm simply suggesting 16k is what I think is the best
small frame size. Patrick is suggesting 4k.
I wouldn't object strenuously to 4k, but my experience and gut both say 16k
is the better choice.

-=R

On Tue, May 28, 2013 at 4:25 PM, William Chan (陈智昌)
<[email-masked]>wrote:

>>> Can you guys clarify this in more detail? Specifically, where the
>>> latency comes from. I have ideas, but I'd rather than an authoritative
>>> explanation.
>>>
>>
>>>> > On May 28, 2013 10:01 AM, "William Chan (陈智昌)" <[email-masked]
>>>> >
>>>> > wrote:
>>>> >>
>>>> >>> > I've been looking at a lot of spdy frames lately, and I've
>>>> noticed what
>>>> >>> > I
>>>> >>> > consider a common implementation problem that I think a good
>>>> http/2
>>>> >>> > spec
>>>> >>> > The muxxed approach of multiple streams onto one connection done
>>>> in
>>>> >>> > HTTP/2
>>>> >>> > has great advantages, but the one downside of it is that it
>>>> creates
>>>> >>> > head of
>>>> >>> > mandatory, but I think we're already in that spot with 16 bit
>>>> frame
>>>> >>> > lengths.
>>>> >>> >
>>>> >>> > -Patrick
>>>> >>> >
>>>> >>> >
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>
>>>
>>
>

---

From: Leif Hedstrom <[email-masked]>
Date: Wed, 29 May 2013 09:17:33 -0600

On 5/28/13 7:12 PM, Roberto Peon wrote:
> I understand what you're saying. We're all agreeing that the max frame 
> size should be limited. I'm simply suggesting 16k is what I think is the 
> best small frame size. Patrick is suggesting 4k.
> I wouldn't object strenuously to 4k, but my experience and gut both say 
> 16k is the better choice.
>

My gut says that 4k is on the small side too. If we left it at 16-bit, but 
with a SHOULD saying only 14-bits are to be used, are we still cutting too 
much rope for people to hang themselves? I'm not suggesting UA developers 
should have to try to optimize for anything beyond the suggested 16KB frame 
sizes, that seems unreasonable and unnecessary.

On the argument side for smaller frames, CPUs tend to get more powerful 
faster than the NIC capacity increases. In my experience, a modern box can 
saturate a 10GigE at the same (small) object sizes as a machine could 
saturate a 1 GigE NIC 4-5 years ago.

Cheers,

-- Leif