Fwd: New Version Notification for draft-kazuho-httpbis-priority-00.txt

Kazuho Oku <kazuhooku@gmail.com> Mon, 08 July 2019 13:00 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 0E2B11201C3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 8 Jul 2019 06:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w-5v9U4VRrd for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 8 Jul 2019 06:00:06 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFADB120198 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 8 Jul 2019 06:00:06 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hkTCz-0004cx-ML for ietf-http-wg-dist@listhub.w3.org; Mon, 08 Jul 2019 12:57:29 +0000
Resent-Date: Mon, 08 Jul 2019 12:57:29 +0000
Resent-Message-Id: <E1hkTCz-0004cx-ML@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <kazuhooku@gmail.com>) id 1hkTCy-0004c7-1x for ietf-http-wg@listhub.w3.org; Mon, 08 Jul 2019 12:57:28 +0000
Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <kazuhooku@gmail.com>) id 1hkTCv-00006f-Iu for ietf-http-wg@w3.org; Mon, 08 Jul 2019 12:57:27 +0000
Received: by mail-lf1-x131.google.com with SMTP id c19so5232319lfm.10 for <ietf-http-wg@w3.org>; Mon, 08 Jul 2019 05:57:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=CU49KcV66G7qBhLkjRs3NnhpPSIITzS1MpDTIWVII5g=; b=S6fTe2rDLGD7yOCNqI4N5UnFZQEfRGgKjhGaCZPzSghba9XyuFC07tuDp8uSOj/408 aqmoYEFftSfXRdDzadEOe9og5htY4eTcKnqHY6tWTXwDrwbAunalMDaTMhENJDk0jnMB kvb//T7Iovdc+rOtp5WjeqVcSJ5dOzetSPmEBt3ixBSiQlR0O2n7+PPvULfEF6n2nSGB iUDxkoTc7HWiepJQMsKMeCvBSRuNYPqj/n7WJsH6/Tt6GoaDAahJJDy6Nb2x6D8j54mJ gX7q2yPpF/3YzjFdfK7nW/SSeucyC4r0K4rXP+B2tQHObfZrgCVsftfTvTFx49HtJacp isQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=CU49KcV66G7qBhLkjRs3NnhpPSIITzS1MpDTIWVII5g=; b=Rp6BozJcdgb747KMANf+RCS5o7yVRaIOZq0gVhNzfkgfrSTacSzkyF2zVRDsLkW1O+ 9drkC/ofEWd2ezidwoe0qDU+fIQvMQASa5lm18tBvdWzV7IG1ll7OZEh326WAuwLumx/ UfECGoUjRwltX/JTwcB+DHls7+WxALa9PICTjMBplBX0zA/L3DPpXd0QiRleF20OLh2W nZ9dgom4oYwCD/l98UHtuF/n4oZ4YDHeKOWjXwKuYpyIjVDw96Tqx2bT0X6okrj0SoB8 UoCZXzeQApqyUZ7IfWY9SYH1lzbDvA1Ch9rY+UaN0e2VB/IbptGikfvfAi/JnxDiUBXP 4naQ==
X-Gm-Message-State: APjAAAVC4ANTt2+cm21JP0C85nyy3fXzYn0nFYQKvnP2R4lFsTYHBgtL tOv8f011823pN/aTf1LmkvaOr/hpwR4uHpwjwmGVTYfG
X-Google-Smtp-Source: APXvYqwJtEu3FqBhpXeDwCv1IjlnL5yRWXI5BV9xXR+On7bk05J1DMeyT+kaS/kle8YrCU2JjoHwNT/4y4AukKNP9ug=
X-Received: by 2002:ac2:5b49:: with SMTP id i9mr8564652lfp.116.1562590623029; Mon, 08 Jul 2019 05:57:03 -0700 (PDT)
MIME-Version: 1.0
References: <156259027635.887.6250697935165505332.idtracker@ietfa.amsl.com>
In-Reply-To: <156259027635.887.6250697935165505332.idtracker@ietfa.amsl.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Mon, 8 Jul 2019 21:56:52 +0900
Message-ID: <CANatvzy7wH=h9tsbzVF9G4Mu5P=RtUMQ1kwAad5H7gpA49Sq+g@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=kazuhooku@gmail.com; helo=mail-lf1-x131.google.com
X-W3C-Hub-Spam-Status: No, score=-2.8
X-W3C-Hub-Spam-Report: AWL=1.333, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hkTCv-00006f-Iu 5816258aa72e4d010467327a95463686
X-Original-To: ietf-http-wg@w3.org
Subject: Fwd: New Version Notification for draft-kazuho-httpbis-priority-00.txt
Archived-At: <https://www.w3.org/mid/CANatvzy7wH=h9tsbzVF9G4Mu5P=RtUMQ1kwAad5H7gpA49Sq+g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36758
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi,

Today, Lucas and I have submitted the following draft, that defines an
HTTP header field for driving prioritization.

https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/

In short, the draft defines an end-to-end HTTP header field called
"Priority" for transmitting prioritization hints in absolute values
that have meanings. It is much simpler than the prioritization scheme
of H2 that communicates and uses a "tree". Not only the client, but
also the server can send the prioritization hints, in order to improve
the way the responses are prioritized. The prioritization scheme is
independent to HTTP versions; it can be used on both H2 and H3 (and
also on H1 for providing hints to intermediaries).

For more detail, please refer to the draft.

Background: back in May in London, the QUIC WG had a discussion on if
porting the prioritization scheme of H2 to H3 is the way to go [1].

I think there were two major arguments for having something different:
* Prioritization scheme of H2 is complex, and porting it to H3
increases the complexity [2].
* With the H2 scheme, it is hard for the server to tweak the
prioritization tree, because clients build their trees in their own
ways [3][4].

The arguments against were:
* Redesigning prioritization for H3 is likely to delay the
standardization and time-to-market.
* Having something different in H3 is an act of "adding" complexity to
HTTP as a whole.

This discussion has led us to wonder if there could be a technical
solution that resolves the issues of the H2 scheme (see the pro
arguments), at the same time minimizing the downsides.

And we came up with this proposal. I think the key selling points of
the proposal are:

* Much simpler thanks to each request carrying an absolute priority
value. No need to synchronize a "tree".
* Because the priority value sent by the client indicates how each
request / response affects the use of other responses (e.g.,
"blocking", "non-blocking"), the server can understand the intent of
the client and further optimize the delivery order.
* Use of the HTTP header field as the conveyer of the priority value
allows an origin server to indicate hints to an intermediary that
terminates the H2/H3 connections from the client. For example, an
origin server can indicate higher precedence for some images that
matter more to the user, while giving lower precedence to others.
* Another benefit of using an HTTP header field instead of a frame is
that prioritization logic becomes independent from HTTP versions. That
would help both clients and servers improve the quality of their
implementation, as well as fostering website owners fine-tune the
prioritization through the use of the Priority response header.
* A header-based prioritization scheme can be improved as time goes,
as HTTP headers are extensible by their nature. It also means that a
header-based design can be rolled out at an earlier stage than a
frame-based design.

To paraphrase, the header-based design provides simplicity,
extensibility, room to evolve, and the possibility to roll out early.
This could be the only prioritization scheme for H3. Separating
prioritization into a version-independent approach simplifies H3,
taking some load away from QUIC WG.

Of course, H3 needs to hit the market with a prioritization scheme, we
need to agree on that particular scheme. But I think we might be able
to agree on the need for a header-based prioritization scheme, that a
server can tweak, that uses absolute priorities. If that is the case,
I think we have fair chance on agreeing on something pretty soon.

To summarize, with the proposed design, I think we have the chance of
making prioritization better as we roll out HTTP/3, without getting
the standardization process delayed.

Please let us know what you think. Thank you in advance.


[1] https://github.com/quicwg/wg-materials/blob/master/interim-19-05/priorities.pdf
[2] https://github.com/quicwg/base-drafts/issues/2739
[3] https://github.com/quicwg/base-drafts/issues/2740
[4] In https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0008.html,
Robin points out that server intervention is necessary for best
performance.

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: 2019年7月8日(月) 21:51
Subject: New Version Notification for draft-kazuho-httpbis-priority-00.txt
To: Kazuho Oku <kazuhooku@gmail.com>om>, Lucas Pardue <lucaspardue.24.7@gmail.com>



A new version of I-D, draft-kazuho-httpbis-priority-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name:           draft-kazuho-httpbis-priority
Revision:       00
Title:          The Priority HTTP Header Field
Document date:  2019-07-08
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-httpbis-priority-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/
Htmlized:       https://tools.ietf.org/html/draft-kazuho-httpbis-priority-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-priority


Abstract:
   This document describes the Priority HTTP header field.  This header
   field can be used by endpoints to specify the absolute precedence of
   an HTTP response in an HTTP-version-independent way.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



-- 
Kazuho Oku