Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY

Roberto Peon <grmocg@gmail.com> Tue, 21 May 2013 21:45 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 3DB4E21F93B0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2013 14:45:28 -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=[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 6IV+OzZs6xwH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2013 14:45:21 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D858B21F93BA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 21 May 2013 14:45:20 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UeuMD-0006gi-KS for ietf-http-wg-dist@listhub.w3.org; Tue, 21 May 2013 21:44:33 +0000
Resent-Date: Tue, 21 May 2013 21:44:33 +0000
Resent-Message-Id: <E1UeuMD-0006gi-KS@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UeuM2-0006e9-BM for ietf-http-wg@listhub.w3.org; Tue, 21 May 2013 21:44:22 +0000
Received: from mail-ob0-f173.google.com ([209.85.214.173]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UeuM1-0001wp-4Z for ietf-http-wg@w3.org; Tue, 21 May 2013 21:44:22 +0000
Received: by mail-ob0-f173.google.com with SMTP id eh20so1375065obb.4 for <ietf-http-wg@w3.org>; Tue, 21 May 2013 14:43:55 -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=tNa+PUwoJKDfk98BmbMI/Y8cuuGRU5rW8LeFKkk+AuM=; b=CCBIVxShz9fEXy+deiEtMopeZLj1W7BI5yTZc79tA0BoT1gf7eJNVfiWf44uJZjZwn 5r6++x2nhCZ90EppsyX2w8LvEbpDOHrzM3bgtfTEg+6+uB1bFKE8mSWqgPH02rB5Sgpe v9TOz23vc6cfn+33p8ODEH1lMxMo4112NL5tx66lziYAEIaxFqc9mi7pm85FhvluFYod WpLwAxlgA7ihXKv19VXR/FYC0X95NFBFPfMsrDE42BRVvgp3DV/MchXTDK7dXnzZO5vT MXwsgYxvQxyaV0lXDyKXMO0JlWDzsx+0ukHFagcw20g/CptvsuKG8G2UuqpnnLBLa8L9 IbkQ==
MIME-Version: 1.0
X-Received: by 10.182.108.194 with SMTP id hm2mr2858143obb.71.1369172635059; Tue, 21 May 2013 14:43:55 -0700 (PDT)
Received: by 10.76.131.232 with HTTP; Tue, 21 May 2013 14:43:54 -0700 (PDT)
In-Reply-To: <CABP7RbeAwrT15QKn5kL0=w+V0zBgObe_pOzT-NxbwSrZ_RyA+A@mail.gmail.com>
References: <CABP7RbfX_H_7dwM7ExL5qJgpV5JN1NYyv9tqnu_E23qGk63mWg@mail.gmail.com> <CAA4WUYhDhoS+BNknRnYLAOXfWzumcjkWnQnM=NkNM8oqqE=atw@mail.gmail.com> <CAOdDvNqkuY5qtOzFz5J0v1F1_n8HmFY9J==sXMs_9tDrTTE=cg@mail.gmail.com> <CAA4WUYhZb_ScYZ=F8ypGkXkX=3oK+4TnyWOtuN_FNkZqqhbZLQ@mail.gmail.com> <CABP7RbeAwrT15QKn5kL0=w+V0zBgObe_pOzT-NxbwSrZ_RyA+A@mail.gmail.com>
Date: Tue, 21 May 2013 14:43:54 -0700
Message-ID: <CAP+FsNd95pXcPM1OiG2qjOyXKV80noh2frdEbORwe6HxsgeK3Q@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>, Patrick McManus <pmcmanus@mozilla.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=089e015365ea8c925c04dd415864
Received-SPF: pass client-ip=209.85.214.173; envelope-from=grmocg@gmail.com; helo=mail-ob0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.678, 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 1UeuM1-0001wp-4Z 3c44b57a14160155539a0be76d7ebdfe
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY
Archived-At: <http://www.w3.org/mid/CAP+FsNd95pXcPM1OiG2qjOyXKV80noh2frdEbORwe6HxsgeK3Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18075
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>

Sending the PRIORITY frame *MUST* cause state allocation at the receiver,
else it was useless to send before the HEADERS frame. As you point out, at
minimum it must allocate a stream ID and priority field, and for most
implementations it will also need to include so mechanism of pointing out
that the headers don't exist, so, probably between 16 to 24 bytes worth of
allocation on a 64 bit machine.

If the PRIORITY frame was renamed to CHANGE_PRIORITY, would that clarify
anything? Priority changing is the current intent of that frame type.

btw, I am not particularly partial to the "any frame opening up a stream"
thing. I'm not completely against it though :)
My reason for slightly preferring that streams must begin with HEADERS or
HEADERS+PRIORITY is that it is an explicit statement of intent, and thus
off-by-one, uninitialized var, etc. errors are more likely to be detectable
in a world where such is required.



-=R


On Tue, May 21, 2013 at 2:19 PM, James M Snell <jasnell@gmail.com> wrote:

> On Tue, May 21, 2013 at 10:30 AM, William Chan (陈智昌)
> <willchan@chromium.org> wrote:
> > Thanks for describing these cases now. I had not thought of them.
> >
> > If everyone's sold on reprioritization, then let's go ahead and do this
> and
> > have the debate about ditching HEADERS+PRIORITY or not. I want to keep
> it. I
> > don't like the idea of sending a PRIORITY frame first. Is sending a
> PRIORITY
> > frame going to trigger stream state allocation at the receiver? What's
> the
> > expectation? And if you don't have a priority for the HEADERS, then you
> have
> > the race that Roberto described.
> >
>
> There is no reason to assume that sending a PRIORITY frame first would
> trigger stream state allocation at the receiver. At most, it would
> reserve the stream ID and store the priority value. The full state
> allocation would not occur until the HEADERS frame is received. That
> said, I'm not 100% dead set on removing HEADERS+PRIORITY, I would just
> like to simplify the protocol where it makes sense to, and even then
> only after it's been proven out in implementation. Having separate
> HEADERS, HEADERS+PRIORITY and PRIORITY frames is confusing, if we can
> do without separating them, we ought to do so.
>
> - James
>
> >
> > On Tue, May 21, 2013 at 2:09 PM, Patrick McManus <pmcmanus@mozilla.com>
> > wrote:
> >>
> >>
> >> On Tue, May 21, 2013 at 12:32 PM, William Chan (陈智昌)
> >> <willchan@chromium.org> wrote:
> >>>
> >>>
> >>> I support adding a new additional PRIORITY frame for stream
> >>> reprioritization.
> >>
> >>
> >> me too. Specifically I support this as a mechanism for the client to be
> >> able to explicitly prioritize an open pushed stream. I can wait for more
> >> evidence about re-prioritizing, but in cases where the client hasn't
> ever
> >> explicitly set the stream's priority I think we have evidence that its
> time
> >> to do something.
> >>>
> >>>
> >>> Unless there's a reason this needs to be in the current http/2 draft
> >>> sooner rather than later, I'd rather punt on this discussion until we
> have
> >>> implementation experience that can guide this debate.
> >>
> >>
> >> I think there is experience here specifically related to push.
> >>
> >> e.g. You can easily configure mod_spdy to push images when html is
> pulled.
> >> but you can't effectively dictate the relative priorities of those two
> >> things.
> >>
> >> Sure, you can define an explicit priority for those images but priority
> >> implementations are all about relative levels and the client set the
> >> priority of the html.
> >>
> >> You can argue that mod_spdy should have defined relative priorities (+/-
> >> the associated stream) instead of constants.. that would be better but
> the
> >> client still has no way to make sure those streams are at a higher
> priority
> >> than a "save as" background stream (I've seen this one happen as
> mod_spdy
> >> defaults to lowest priority when pushing), or a lower priority than a
> >> real-time video stream..
> >>
> >> plus there is no scale for the server to work with.. it might set a +2
> >> priority for pushed images but the client might be using +3 for pulled
> >> images causing a mismatch in something that was intended to be equally
> >> weighted.
> >>
> >> at least with a priority frame the client can make those adjustments in
> a
> >> RTT.
> >>
> >> Cheefully,
> >> -Patrick
> >>
> >>
> >
> >
>
>