Resent-Date: Tue, 28 May 2013 18:51:03 +0000
Resent-Message-Id: <E1UhOz9-0006LE-KA@frink.w3.org>
MIME-Version: 1.0
In-Reply-To: <CAP+FsNdejY=K4fp6jMh1AzSkMpdxWNd+cCnaF6uw2GPfMVtjAA@mail.gmail.com>
References: <CAOdDvNoAjiRSBv9ue6RgCQJ4wMNQcKBH2a8zVa4_96wbp=g8MA@mail.gmail.com>
 <CABP7Rbefh0HxT7Pui_F8viNvu8232O3Qt=VaR6SgsL1DQarVSA@mail.gmail.com>
 <CAA4WUYgKsDudsSAywWSwz5KVsEV5iUREqjmYVB5sWuc+11ujOQ@mail.gmail.com>
 <CAP+FsNdejY=K4fp6jMh1AzSkMpdxWNd+cCnaF6uw2GPfMVtjAA@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Tue, 28 May 2013 11:50:04 -0700
Message-ID: <CABP7Rbf6Ls8pBf9Rons9hgLeXjnm-yk6t6kebk1EXcS3bTdf_Q@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Will Chan <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>,
 Patrick McManus <mcmanus@ducksong.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.214.169; envelope-from=jasnell@gmail.com;
 helo=mail-ob0-f169.google.com
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
Archived-At: <http://www.w3.org/mid/CABP7Rbf6Ls8pBf9Rons9hgLeXjnm-yk6t6kebk1EXcS3bTdf_Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

On Tue, May 28, 2013 at 11:41 AM, Roberto Peon <grmocg@gmail.com> wrote:
> As a reverse proxy, I've seen properties for which 4k writes/reads were t=
oo
> small and induced latency increases.
>

I haven't played with this part too much yet but this is my general
suspicion also.

> Admittedly, frame size doesn't have to be the same as read/write size, bu=
t
> 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 t=
hat
> 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.
> -=3DR
>
> On May 28, 2013 10:01 AM, "William Chan (=E9=99=88=E6=99=BA=E6=98=8C)" <w=
illchan@chromium.org>
> wrote:
>>
>> Can you clarify what you mean by a documented performance metric for
>> non-browser use cases? I don't think Patrick said anything browser speci=
fic.
>> He provided some serialization latency numbers and noted that they are h=
igh
>> enough to impact responsiveness. And then he provided numbers on overhea=
d.
>>
>> 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 woul=
dn't
>> complain about it. And in absence of complaints, I guess I'd support mov=
ing
>> forward with only 12 bits for length.
>>
>>
>> On Tue, May 28, 2013 at 9:22 AM, James M Snell <jasnell@gmail.com> wrote=
:
>>>
>>> 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 <mcmanus@ducksong.com>
>>> wrote:
>>> > Hi All,
>>> >
>>> > I've been looking at a lot of spdy frames lately, and I've noticed wh=
at
>>> > 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 one=
s
>>> > 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 t=
he
>>> > 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 t=
o
>>> > 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 g=
et
>>> > 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
>>> >
>>> >
>>>
>>
>