Re: [WARNING: ATTACHMENT(S) MAY CONTAIN MALWARE]Re: HTTP(3) priorities

Kazuho Oku <kazuhooku@gmail.com> Fri, 26 July 2019 13:51 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 C911312001E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Jul 2019 06:51:38 -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=unavailable 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 y-0dEWLQfYxX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Jul 2019 06:51:37 -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 0597112001A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 26 Jul 2019 06:51:36 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hr0aj-0007Ti-Jo for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Jul 2019 13:49:01 +0000
Resent-Date: Fri, 26 Jul 2019 13:49:01 +0000
Resent-Message-Id: <E1hr0aj-0007Ti-Jo@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 1hr0ag-0007Rv-3j for ietf-http-wg@listhub.w3.org; Fri, 26 Jul 2019 13:48:58 +0000
Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <kazuhooku@gmail.com>) id 1hr0aa-0001Ea-CB for ietf-http-wg@w3.org; Fri, 26 Jul 2019 13:48:57 +0000
Received: by mail-lj1-x231.google.com with SMTP id i21so51575869ljj.3 for <ietf-http-wg@w3.org>; Fri, 26 Jul 2019 06:48:31 -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 :cc:content-transfer-encoding; bh=tfxdA0aqoeACbyJK5nmkbbGy/6Q/SKyJyl/q1VvcGrg=; b=psJcPX3kMvqySyVnc5+r3Wz7X4Cxzoq9dEDLtMnCQJ08Uva46akrl9eLp6hw9WXMSe nyZCIB8KnisUeyMTZDHVdy2EMlIQodk2DXchYx/RTsmOMdcqoCYb4PzRTxTdUPwsVwvM Ez5EXLutwaCaSjte9n3cGErsuRp0wwQYZmhnEVKcRED0AZVv0JqZaTtC5VVSq4tJz2Gl Zj0hCdW3bT5+VwtbmwBKdadYqGF9jpWVYAUmh2BP5Bcmf7XABmGyNqU2OT/f95xNS8/b 1K51G42Cqr72C3RujYfzHVivpecxJatDZI0B3FKOe/01pKvzhgAMV9jUE7FFj/LqlNSm KZqA==
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:cc:content-transfer-encoding; bh=tfxdA0aqoeACbyJK5nmkbbGy/6Q/SKyJyl/q1VvcGrg=; b=m41LeVfh5RSOMRV5b00V9kESnrs3CqBvIqAFQtBt3d0AyoXiPQCYTz3qj6cX2DTTCS mn1NXw+qiPDJH5P4E6Vy52nKWNSm9REh0egB4N3hnhxW8UirhV51lO9w1EBwC4mBe96f jIAZmnPXXGFNpSxvdSmHUuNnvQsO+N/SGKxVe7IRhvRh1qFV63nGZR2MiBVesSIFlvb0 Wqvs2Zv6VonNBDtpkWZ1sRHCJzSDHzNAHexpMmY6PYBVYSTulDscqhPwEJr8iLZfF9oL WvP4b+Wn+RY/z3g8Un7fUNsauNfuo7aHFgnSkzHpFd7VznrU1fJjq2N1rZ1vhtEa+RMy ZmtQ==
X-Gm-Message-State: APjAAAXozQUbrkMx7RtVQ6/LQUX+w4PoOoeD3ZNi/b0OOjW7MoMW6Pmy Fb5tBAK/Efv0/OeshPVpB+RFkZ0soIj6BeVdcIo=
X-Google-Smtp-Source: APXvYqwIO4PkbTRbEZHSl0BPG6/9uAlJ/T3XVgPZVnF6BhZ5rsLf9R0m1nin+rFyAfZALW8YeBVD3oV6naSBHLZd6cs=
X-Received: by 2002:a2e:9b03:: with SMTP id u3mr29813024lji.15.1564148910365; Fri, 26 Jul 2019 06:48:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAKcm_gOzeufrZua5Y9HSVKn3UeuA+XM9bBmEw8W6LdtfhE5LDg@mail.gmail.com> <CANatvzw0rzbDFoc4GZy=KMsDT2udS1PwEK9uXJ4+HsA9CTtYcA@mail.gmail.com> <564520DD-2BAE-48EE-9041-3FCF5531328A@vcontractor.co.za>
In-Reply-To: <564520DD-2BAE-48EE-9041-3FCF5531328A@vcontractor.co.za>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 26 Jul 2019 09:48:21 -0400
Message-ID: <CANatvzzrzT4_ANs_8uGd2jCPN38cmatcrm_c6Kavdn6BE-s7yg@mail.gmail.com>
To: "Oliver, Wesley, Vodacom South Africa (External)" <Wesley.Oliver@vcontractor.co.za>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>, 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::231; envelope-from=kazuhooku@gmail.com; helo=mail-lj1-x231.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 1hr0aa-0001Ea-CB 3f7997a19c38f01f7c064c4ebffae472
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [WARNING: ATTACHMENT(S) MAY CONTAIN MALWARE]Re: HTTP(3) priorities
Archived-At: <https://www.w3.org/mid/CANatvzzrzT4_ANs_8uGd2jCPN38cmatcrm_c6Kavdn6BE-s7yg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36846
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 Oliver,

Thank you for your comments.

Being a server developer, I like the idea of splitting the urgency
groups, but I am not sure if we should bake something that we *might*
want to use into the core design. IIUC, your suggestion is to have a
more fine-grained signaling between the web application and the H2/H3
terminator. Assuming that is the case, these two parties can do an
experiment, by defining a proprietary parameter of the Proxy header
field, do the experiments, then ask for it to become an official
extension.

Now that we are dropping support for priorities in H3, it is
beneficial to have some alternative shipped at an early moment.

Therefore, it is my view that we should first standardize something
minimally viable, based on what the clients and servers already do, at
the same time leaving room for experiments and improvements. While I
agree that having 20*8 urgency levels is possible, it is complex than
just having 8 urgency levels. Broad adoption of the H2 prioritization
scheme happened, even though it was implementable. At least two
large-scale server operators do support it the way spec is written.
But for others, it seemed too complicated. I think we would like to
minimize the chance of repeating that failure.

Regarding your other comments, I am not sure if I am following, but I
do not think that routers or switches would deal with the HTTP-level
priority information. Plaintext H2 is not a thing, and H3 will always
be encrypted. It is also my understanding that sending some packets of
a connection with a different QoS label is a bad idea, because doing
so would have bad impact on loss recovery and congestion control. I
could be wrong (or there might be some solution that I am not aware of
- I'm not a transport persone), though.

2019年7月25日(木) 2:48 Oliver, Wesley, Vodacom South Africa (External)
<Wesley.Oliver@vcontractor.co.za>;:
>
> Hi,
>
> The only thing I could suggest is that you make those priority flags increments of 20,
> So that if there are changes or minor priority preference per website, then
> That in between numbers can be used. If there is any new future priority conventions
> Then just add them in the middle of the 20 group splitting the existing group.
> Maybe make the field 2 bytes, which allows for future expansion, were there are many files, streams
> Which require a new priority order.
>
> Otherwise one needs to build a priority map, over the deps, converting a high resolution to low resolution.
>
> Kind Regards,
>
> Wesley Oliver
>
> > On 24 Jul 2019, at 19:14, Kazuho Oku <kazuhooku@gmail.com>; wrote:
> >
> > Hi!
> >
> > Attached are the slides that Lucas and I presented during the side meeting.
> >
> > Thank you all for the feedback.
> >
> > 2019年7月9日(火) 21:00 Ian Swett <ianswett=40google.com@dmarc.ietf.org>;:
> >>
> >> There has been quite a bit of discussion of HTTP priorities lately on both the QUIC and HTTP mailing lists, with more to follow.  The plan for IETF in Montreal is as follows:
> >>
> >> Monday: Overview of priorities for 15 minutes in HTTP, with 15 minutes discussion.
> >> Wednesday: A side meeting will be held from 8:30-9:45am in Van Horne.
> >> Thursday: I'll summarise the side meeting in Wednesday's HTTP session.
> >>
> >> Thanks, Ian
> >
> >
> >
> > --
> > Kazuho Oku
> > <The Priority Header Field.pdf>
>
> This e-mail is classified C2 - Vodacom Restricted - Information to be used inside Vodacom but it may be shared with authorised partners.
>
> "This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this linkhttps://www.vodacom.co.za/vodacom/terms/email-acceptable-user-policy"



-- 
Kazuho Oku