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

William Chan (陈智昌) <willchan@chromium.org> Tue, 28 May 2013 19:19 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 480EF11E80DE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 12:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 mCxxPG+yaqy5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 12:19:08 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 872C511E80E0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 May 2013 12:19:08 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UhPOs-0003GU-2v for ietf-http-wg-dist@listhub.w3.org; Tue, 28 May 2013 19:17:38 +0000
Resent-Date: Tue, 28 May 2013 19:17:38 +0000
Resent-Message-Id: <E1UhPOs-0003GU-2v@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UhPOe-0003Fk-Dm for ietf-http-wg@listhub.w3.org; Tue, 28 May 2013 19:17:24 +0000
Received: from mail-qe0-f43.google.com ([209.85.128.43]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UhPOY-0005TQ-Dz for ietf-http-wg@w3.org; Tue, 28 May 2013 19:17:24 +0000
Received: by mail-qe0-f43.google.com with SMTP id k5so4608237qej.30 for <ietf-http-wg@w3.org>; Tue, 28 May 2013 12:16:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hUZFfWATdGEqo9D3fOPHLh+EQVl3TPc9JSg/HmgvOKE=; b=J/Klh3xBcCKqYYeE48I5hrhLX3Ner5WwBHldg8ED7ZttPQIsXsu+MKXF42+J7elPxa r4RGFehcAtPWN11JrTEn5d3kQjINZK1BW7qEhcRs+WtNdJYQy7C5Z14SfRHJOlsGqql2 OnwsSOflmBn97NN5tJc5yGXKsW5oeB3mCEgqF+St37mxIlaBmmvJxqG0YrM+G0/5wd3l n8KPxnCZCgiUJ+Hr+t5SXSL+qox45AYfC46tL1gatb24tuUVo6gTql81LxyGWtO7KCXR q6qEgMih75C8d5bOn9uypywOeH2UoDFXwC6XWPI7W/u6MMTtHfVsf4j1XHtHkRVdhjI/ OVYQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hUZFfWATdGEqo9D3fOPHLh+EQVl3TPc9JSg/HmgvOKE=; b=Zzi+N4/mQVJ8z6oRlHEgS1wvCrwPG0kXE5Nc7nZC/mEX4dPNfYLNZyXQdZAlHOykkP fmdFV9AN/9xJmfWBiHi+4IQw4v4/SguSipke3/qlCqrLL6jJJACH4Hgh7L49r/N88dPs 19eleO30Yd83OMPTWXNLmmgxd1tZoyFKmyNyE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=hUZFfWATdGEqo9D3fOPHLh+EQVl3TPc9JSg/HmgvOKE=; b=Srt+AFPFkW0mkkkWBTgRc4dynF9NZ2YRFBhbGKXQT+ASXWkkpe3/nsBbXpu4aAyox+ WoDjLPR1jGCULLm+/X57kpX3ZULWMoNSmBHPt79Akr8FgnkB+osONlt7Omf1XOeqRqHU 2szZ/oJECCHPRuaCG55Egt51t4nVTkwarRFtufCnEMosou1mZK+6BS+Ml0lx2EmNLqId Pd6f+JOtDVQz/OJNHHK4EwS9ewKkZqOKM8T6S0fT8cVsiirKqDzXOSOg2vKsDC4xdeId yn9oXitCNTS4IOutDwzAvGHY0hH+4djzzR4Nopbus23K9W9A8m6EkTsXrdnDnqZuZeZp FFoA==
MIME-Version: 1.0
X-Received: by 10.229.38.7 with SMTP id z7mr3099809qcd.140.1369768612589; Tue, 28 May 2013 12:16:52 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.62.133 with HTTP; Tue, 28 May 2013 12:16:52 -0700 (PDT)
In-Reply-To: <CABP7Rbf6Ls8pBf9Rons9hgLeXjnm-yk6t6kebk1EXcS3bTdf_Q@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> <CABP7Rbf6Ls8pBf9Rons9hgLeXjnm-yk6t6kebk1EXcS3bTdf_Q@mail.gmail.com>
Date: Tue, 28 May 2013 12:16:52 -0700
X-Google-Sender-Auth: coLPpEWU4bGLyxZME-K_WX-d0Gw
Message-ID: <CAA4WUYjGk5EYeP9pP=TDWdGGyq5PjwHcDc+qD1mBGuSAt9yvng@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
Content-Type: multipart/alternative; boundary=001a11c2ca74942fac04ddcc1b4a
X-Gm-Message-State: ALoCoQlSa+PR3r+j0Ntu7+bLEqYe4uBT/Cync6z3ts9CIqj1+IFxXZqe7+fmJ5LK0Y87tVHGYCrvGrv6OG30sX6n3hj7SF14Nzs3iBNjLkzP8mDd9JBbz8FPjnlibnzAPU8BmH7wGFbF9gh9Vacwi2rM52lIKMMf/9J8vNrk471Fj/6f+XDnJI+UG8tnV+HR5gVECO777KoH
Received-SPF: pass client-ip=209.85.128.43; envelope-from=willchan@google.com; helo=mail-qe0-f43.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: AWL=-2.200, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.07, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UhPOY-0005TQ-Dz a84c14a49e216563f25f2381cd9d5475
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
Archived-At: <http://www.w3.org/mid/CAA4WUYjGk5EYeP9pP=TDWdGGyq5PjwHcDc+qD1mBGuSAt9yvng@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18121
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>

On Tue, May 28, 2013 at 11:50 AM, James M Snell <jasnell@gmail.com> wrote:

> 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
> too
> > small and induced latency increases.
> >
>
> I haven't played with this part too much yet but this is my general
> suspicion also.
>

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.


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

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.


> >
> > 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
> >
>
> 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
> >
> > On May 28, 2013 10:01 AM, "William Chan (陈智昌)" <willchan@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
> 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 <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
> 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
> >>> >
> >>> >
> >>>
> >>
> >
>