Re: Priorities I-D for Thursday HTTPbis meeting (Fwd: New Version Notification for draft-kazuho-httpbis-priority-04.txt)

Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 21 November 2019 02:54 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD2F12091F for <quic@ietfa.amsl.com>; Wed, 20 Nov 2019 18:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 nWCwO-Vysir5 for <quic@ietfa.amsl.com>; Wed, 20 Nov 2019 18:54:05 -0800 (PST)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F429120840 for <quic@ietf.org>; Wed, 20 Nov 2019 18:54:05 -0800 (PST)
Received: by mail-vk1-xa32.google.com with SMTP id t184so379621vka.1 for <quic@ietf.org>; Wed, 20 Nov 2019 18:54:05 -0800 (PST)
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; bh=auyYUZzFdGv5mqRWRprKllOITZOPKThfviYjocKp4pg=; b=hqbu48kPyiiAj4WIA8TBgiO41Sd6UwzBN48+HOslq/P4qRMk+/YmEnv6yI4apV3I55 FU5n2ckTGtNJGjA6GwE1dXe7KIxscQoKqqGweeYLw26jQXq+wBan9Zb1rlCs/eXVGn2J RfEg7cP5djV+oR1GsQwL+YKlrGHlPPRUKzEY5898iwFDQ0y07nHdC7mjgiPIhTX1Jcxh XWb2B+2/khC7ozotoAhmX/hAzaYGxg9YMwksuALJ9i+koJl//BA8sjrWjlFmsRba68xk 4GG7mdJ8/d+uzn0nDit/M9x3hbDy3lRbyd+aPssqwWHyc6wliK2WPxAEGw5Ad6rD84Rd FW9A==
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; bh=auyYUZzFdGv5mqRWRprKllOITZOPKThfviYjocKp4pg=; b=J3NLgebruyPRbSG3vYo1K2N2Y5vc2LDllG6efF1+J4Myx4DxDvzYwfb4s3FiMSOkBi oLgvqIUu5bQufEWY8PwvMN49qGDijnJixpFJB7VI+bf7X6Tm7relFxR6Lh4hED4G6mUS dH5P7CaDmlX1+UKonDy2ngEb9VJjiW7f9BVa87GEaTRyDMGporBMI7bE9QaMZerpVoH3 Xgw8udcj9AQM6Br5W8phVhYZ5+lXEaOgFN2creoi9G0CvPsh7XXj0wxvriyOdQVRmy4f XVIniUQSVkF+sO16RYnHauGk0Pgx4IX+09k+EJ1xZYrLoQeCr3pzWkQniz0bTwgmJSH1 4tcg==
X-Gm-Message-State: APjAAAU0kjIohiPzmMNV5iYj8wfpnPDlGZvDetLpBlk/kptzuwZIWMqe uvTwGOU60G6EVHxrnptYt4Ei6+o1ulvld8glWSE=
X-Google-Smtp-Source: APXvYqxFpbZlD74uzjoNhDYc9d4tqAt5kdLC73vUxh0++BU//GUeULliMH/rHqml6yP6ofzlTJdcT+Dw3AEh5laomEA=
X-Received: by 2002:a1f:a752:: with SMTP id q79mr4054769vke.67.1574304844648; Wed, 20 Nov 2019 18:54:04 -0800 (PST)
MIME-Version: 1.0
References: <157425081947.30550.7403247942771684795.idtracker@ietfa.amsl.com> <CANatvzyk6xaDby-VVvtuOJ66=YPMqynB9=WMAMxYPxGXYa=BPA@mail.gmail.com> <d651767a-8b6c-4e45-b154-ef1ad0bf34a3@www.fastmail.com> <CANatvzwqzrkf_JpAcR+K=T5RbHtTAXyL7ZPE7NTcCfXfEB5JSw@mail.gmail.com>
In-Reply-To: <CANatvzwqzrkf_JpAcR+K=T5RbHtTAXyL7ZPE7NTcCfXfEB5JSw@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 21 Nov 2019 02:53:53 +0000
Message-ID: <CALGR9oYECqXarT+pdCKG5QuQ26KxvSifmmtbpbAujYENJpOOOQ@mail.gmail.com>
Subject: Re: Priorities I-D for Thursday HTTPbis meeting (Fwd: New Version Notification for draft-kazuho-httpbis-priority-04.txt)
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Martin Thomson <mt@lowentropy.net>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000896c40597d26991"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/pkmC4b4wA2RCE_HIbGJzGAEnBd8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Nov 2019 02:54:07 -0000

To put my own thoughts on top of some of Kazuho's

On Thu, Nov 21, 2019 at 2:16 AM Kazuho Oku <kazuhooku@gmail.com> wrote:

>
> Can we look to simplifying this a little more?  I understand that
>> reprioritization was identified as being important by the design team, but
>> I don't recall seeing ever any evidence to support that view.  Can we split
>> that piece out and maybe pursue it separately?
>>
>
> There seemed to be certain amount of agreement that three features
> (client-driven prioritization, server intervention, reprioritization) was
> necessary. That said, I agree that we can cleanly split reprioritization
> from the scope of the draft, and at the moment I would not oppose to that
> if that is the preference of HTTP WG.
>

I opened issue #1 on draft 00 as a question on reprioritiation. But I think
the important question to ask is, if we as WG agree to deprecate "HTTP/2
priorities" does that mean the signal, the tree-based model, the features
(setting, mutating, etc) or all of the above. My own view is that we are
not deprecating the features but instead grandparenting them in
unquestionably. The question of importance of reprioritization is totally
valid but I think it is unfair to place the burden of proving its
importance in a replacement, when RFC 7540 does not describe why it was
important in the first place. That said, I would be willing to explore this
further, and support the notion of a separate document but will caution
that carving the feature set too much will increase the chance that
implementers get this new scheme wrong by making assumptions based only on
initial priority. This is not a theoretical risk, there is a large survey
of reprioritization in the wild for some specific cases [1].


>  I would prefer to frame the way in which priorities are "merged" (Section
> 6) differently.  I would instead say that the priority information is input
> to prioritization decisions that endpoints/intermediaries/etc.. make.  So I
> would instead say that these entities simply make their own decision about
> the way to incorporate these signals into their decision.  That's probably
> a systemic thing that affects more than Section 6; I see that the draft
> uses "obey" in Section 7.1.1, for example.
>
>>
>> There seems - at least to me - to be an assumption on the part of some
>> people involved in this that Priority will be interpreted as an
>> imperative.  That is, that a client might be able to tell a server to act
>> in a particular way and expect to have that instruction complied with.
>> Same for servers and proxies.  That might be an appealing, but I can't see
>> any way in which we can rely on that.  To the example in the draft, as a
>> CDN, I would expect that the server's view carries more weight than the
>> client's, but I wouldn't necessarily say that this something as absolute as
>> is currently implied.
>>
>
> I agree that the priority parameters are merely hints, and that we do not
> need to mandate exactly how they would be implemented. Though I think we
> need to provide expectations on how H2/H3 terminators are expected to
> prioritize is important for other endpoints using the signal.
>
>
I started a PR to tackle explanation some of the issues about merging
/collaboartion. I closed that closed it because I wasn't sure if useful,
but it sounds like there is some value and I can resurrect it.

Cheers
Lucas

[1] https://github.com/andydavies/http2-prioritization-issues