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

Patrick McManus <pmcmanus@mozilla.com> Tue, 21 May 2013 17:10 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 D8A5921F968F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2013 10:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.367
X-Spam-Level:
X-Spam-Status: No, score=-9.367 tagged_above=-999 required=5 tests=[AWL=0.309, 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 5lARg-uAnF-c for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2013 10:10:52 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B018321F961C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 21 May 2013 10:10:44 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Ueq4P-0006tx-FG for ietf-http-wg-dist@listhub.w3.org; Tue, 21 May 2013 17:09:53 +0000
Resent-Date: Tue, 21 May 2013 17:09:53 +0000
Resent-Message-Id: <E1Ueq4P-0006tx-FG@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1Ueq4D-0006re-Pj for ietf-http-wg@listhub.w3.org; Tue, 21 May 2013 17:09:41 +0000
Received: from mail-oa0-f43.google.com ([209.85.219.43]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1Ueq4B-0006gz-Tx for ietf-http-wg@w3.org; Tue, 21 May 2013 17:09:41 +0000
Received: by mail-oa0-f43.google.com with SMTP id o6so1156414oag.16 for <ietf-http-wg@w3.org>; Tue, 21 May 2013 10:09:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=9aAeqnDNAI34hbaKhfobHiJwEanrcd8kqTITI1nZkQ4=; b=0gLdlMGa8n8+i9ebonig2QKsJD6eUF27+cY4fEwxuASaHGI42NTW0WkaH+qaNpa9Yp AVgwK5XW3laM5/2GcLm1yuWpq37Snlh+C1d9ZoSfOtdz/mt3/KPvUXiiySid2BTHm0F+ UP5dlR6TG7IGmZkCIbSZR6JyFanQpNyeeXXXrkhEoaPuZDe2nzJFndPM29XfnL8qM31T ccVvY8uBVGBtIBPuePDL4UYCMaqea2bvOC5aFtS/Wc+h22XKxOyAiTlttU7HNS4Ufhq5 0zFuaYI16G73J2g0YxCyBnGGZf//1jbzcCZq1obnPtboLKqw5AjylE4H//67k44Hgfcp dr1Q==
MIME-Version: 1.0
X-Received: by 10.60.57.201 with SMTP id k9mr2081780oeq.30.1369156153679; Tue, 21 May 2013 10:09:13 -0700 (PDT)
Sender: patrick.ducksong@gmail.com
Received: by 10.76.13.193 with HTTP; Tue, 21 May 2013 10:09:13 -0700 (PDT)
In-Reply-To: <CAA4WUYhDhoS+BNknRnYLAOXfWzumcjkWnQnM=NkNM8oqqE=atw@mail.gmail.com>
References: <CABP7RbfX_H_7dwM7ExL5qJgpV5JN1NYyv9tqnu_E23qGk63mWg@mail.gmail.com> <CAA4WUYhDhoS+BNknRnYLAOXfWzumcjkWnQnM=NkNM8oqqE=atw@mail.gmail.com>
Date: Tue, 21 May 2013 13:09:13 -0400
X-Google-Sender-Auth: GQZpOsT79F66ihRfGVF6ahPWUUg
Message-ID: <CAOdDvNqkuY5qtOzFz5J0v1F1_n8HmFY9J==sXMs_9tDrTTE=cg@mail.gmail.com>
From: Patrick McManus <pmcmanus@mozilla.com>
To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
Cc: James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=089e0118299e2eb0db04dd3d8204
Received-SPF: pass client-ip=209.85.219.43; envelope-from=patrick.ducksong@gmail.com; helo=mail-oa0-f43.google.com
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-2.564, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1Ueq4B-0006gz-Tx 39bb6966315f6b29d770d3c5e068759d
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/CAOdDvNqkuY5qtOzFz5J0v1F1_n8HmFY9J==sXMs_9tDrTTE=cg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18061
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 21, 2013 at 12:32 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote;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