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

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Sat, 23 November 2019 10:52 UTC

Return-Path: <mikkelfj@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 80F8112011E for <quic@ietfa.amsl.com>; Sat, 23 Nov 2019 02:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 rqFXRQtweJPC for <quic@ietfa.amsl.com>; Sat, 23 Nov 2019 02:52:38 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 A691A120106 for <quic@ietf.org>; Sat, 23 Nov 2019 02:52:37 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id a21so8222604edj.8 for <quic@ietf.org>; Sat, 23 Nov 2019 02:52:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=TO5gZG6dZC44uYURMcL845Y3eQI10cTo7+JWGPm7cC0=; b=EBIEDeeC41FTD/WC67a1w7sxj+brDwHoqJ7RrT0766+83y5F/qRWdwuxdiCZevvP5I JDzTO55T42bqisi7wHdCifznB2V0zMYPTYeQvCpMGn+9r4g7bBF4Fy2/MjrrmAtSb/j8 eCQxxiruxHerm+Qf4ep4q8cZ6+RJfaGSXVt6XjlYdtHN0hshp+zmjP50wTdXYKlT4Ke7 nNqc3q5jVPlQstTVlYn0myG2qOulfTtCBXepSIsbDdzsF3C9STO8Ol2kyikJI37cv/uV G2tThmvOv98Ngt8rz+7UCfzIB+w+qRVM4h09lAh/yx26UMb/cukk1z4mEdONsEMPLFPS CfVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=TO5gZG6dZC44uYURMcL845Y3eQI10cTo7+JWGPm7cC0=; b=pLm4PFhiXk+FPISCVTjYNE2A0UvP3ZgtP9wgUQwEr6CG3qcHKmkO+oxCUr1OCeqguv qB22lhSuaxfLW6WVjcuhwAQ7ASjVkoriEt0YVqTMzL9HS5xY2mKJE81cBW/PUuIhnCTT 4odwiEtJA4oDB09HlNmnbwgxKofAXO5W/WlIikmNKUqLl0ITsOjO8+bWHL8ZvBtYdTg1 wgU+a/5K7HGC2eHgWGOyYKUszwFZYJa/VY88syAE9MftZdCP9gsm6p3MYW6qObTj+LUF 2rxLtggSXBJ2OwJOeaTiyynppOo2n7xWe8KX0Vu7xQq3fDsLHnmLdnCtKkf9/4rPvWRz 2UZA==
X-Gm-Message-State: APjAAAV89Bja/c1EXHA/0XzCZAj7AmtuAeyOr7B63nmrFKwABK4QRw69 uhE+BNuiUPpRY9gjUi2T2eChlVA5me0JHWBfOB0=
X-Google-Smtp-Source: APXvYqwtaA7HGE3kqT9bH8L+Hqfm9vVV6WjEeO/zeJABQGLiwJTsw0mfxTllzSnyeyc2jQ1JKEnb/UFo91kbhBdnsNg=
X-Received: by 2002:a17:906:1b41:: with SMTP id p1mr26502471ejg.65.1574506355957; Sat, 23 Nov 2019 02:52:35 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 23 Nov 2019 05:52:35 -0500
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CALGR9obRoQ56Jcf_UMW0qiHgGmeRt1y8+8A_8T55XrtgUsWR1g@mail.gmail.com>
References: <157425081947.30550.7403247942771684795.idtracker@ietfa.amsl.com> <CANatvzyk6xaDby-VVvtuOJ66=YPMqynB9=WMAMxYPxGXYa=BPA@mail.gmail.com> <CAN1APddw53xtus9Z86H4rw2CRXA3MR+fxhLWPf3Bh_=qB-O7Aw@mail.gmail.com> <CALGR9obRoQ56Jcf_UMW0qiHgGmeRt1y8+8A_8T55XrtgUsWR1g@mail.gmail.com>
MIME-Version: 1.0
Date: Sat, 23 Nov 2019 05:52:35 -0500
Message-ID: <CAN1APdcPf3EZDRyhVFJdUK9o5UtZYbzMWfJM_MAbhgZh=U2L1Q@mail.gmail.com>
Subject: Re: Priorities I-D for Thursday HTTPbis meeting (Fwd: New Version Notification for draft-kazuho-httpbis-priority-04.txt)
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: QUIC WG <quic@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000000b275d059801544a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HjZ47szyAyYp8J66xM3fR4HkpKo>
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: Sat, 23 Nov 2019 10:52:39 -0000

comments inline

On 20 November 2019 at 20.18.46, Lucas Pardue (lucaspardue.24.7@gmail.com)
wrote:

Hi Mikkel,

To comment as a co-author but speaking only for myself:

On Wed, 20 Nov 2019, 20:57 Mikkel Fahnøe Jørgensen, <mikkelfj@gmail.com>
wrote:

> Looking forward to digging further into this.
> ...
>

>
> After reading 1/3 of document, I still have no clue how the priority
> scheme works (except I have some guess based on earlier ideas that have
> floatet) and I have had to deal with a lot of HTTP/2 legacy that I am not
> necessarily interested in. HTTP/3 doc has also move away from implicit
> HTTP/2 familiarity, at least last time I checked.
>

To reinterpret you point, I think that the concepts of urgency and
precedence would benefit from better description (issues #31[1] and
#32[2]). But I also wonder if you are saying that there is too much or too
little HTTP/2 specific/related content? Or am I missing out on your point
here?

Yes, I think an overview of the mechanism is needed. This email was up to
section 3.

On HTTP/2 I think it is warranted with a good explanation. I don’t think
more is necessary, and perhaps there is enough, but it is placed too early,
forcing focus on things that may not be material to the reader and confuses
grasping the core concepts.

Reading further, I don’t bother to comment, but a general observation was
the each section raised questions that were answered in later sections -
it’s hard to address all at once, but worth keeping in mind. A minor thing
is the inline graphics which intuitively, to me, means hex encoded SVG og
PNG, but that is not what is meant, and at the very end that becomes clear.
A larger issues are why servers send priorities in the first place (it is
eventually explained).





> The document talks about intermediate hop reprioritisation without making
> clear what that is or what purpose it serves. I can only assume load
> balancers and reverse proxies. From a QUIC background that also leaves me
> wondering what that means - since each hop is necessarily also end to end,
> unless there is an extension wrapper frame, but that makes no sense.
>

The intent is to address the HTTP semantic layer but dip into HTTP
version-specifics where necessary. We rely on readers being familiar with
HTTP semantic concepts and terminology but can probably do a better job of
referencing. Since QUIC has no concept of priority, but the serialisation
of HTTP does and is ultimately coupled to the transport layer, it can be a
bit tricky to pick the subject. Happy to take some suggestions on specific
ways to improve here

Intermediates are explained when reading all the way to the end, but it is
an example of confusion that arises while reading through the document. On
HTTP version neutrality I think that is fine, but it would help to be more
expliciit bout this, and mention why there are frames in some versions,
without going into details. As it is, the text appears a mixture of general
headers, and constructs (frames) that do not necessarily make sense, and
misleading because the heavy text HTTP/2 might lead one to think that it is
possibly only, or mostly, intended for HTTP/2.


> Once I got to the business end of the document, the document starts by
> telling which headers not send when it is not at all clear what those
> headers are about in th first place.
>
> It’s also confusing what a protocol specific frame means, or why it cannot
> all be done with HTTP headers.
>

It would help to point to a specific section or paragraph. RFC 7540 Section
8 and HTTP/3 draft 24 section 4.1 detail message exchanges - I don't
especially feel the need to duplicate text in this document but accept that
it might help to reference these in the text.



Start of section 3, quote below. This text assumes detailed knowledge of
later text. It would be better to state that certain restrictions apply as
discussed in section (whaterever later section).

" If

   intermediaries want to specify prioritizaton on a multiplexed HTTP
   connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT
   change the Priority header field.

“



Cheers
Lucas