Re: [Tsv-art] Tsvart last call review of draft-ietf-httpbis-priority-10
Bob Briscoe <ietf@bobbriscoe.net> Mon, 27 December 2021 23:18 UTC
Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B443A152E; Mon, 27 Dec 2021 15:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.938
X-Spam-Level:
X-Spam-Status: No, score=-3.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 q9LpMDGqGT3p; Mon, 27 Dec 2021 15:18:11 -0800 (PST)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 B95DE3A1528; Mon, 27 Dec 2021 15:18:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CzYUk29tf9eEinAzWhmzAqySSjUpDIM+9g7JjN2oQTY=; b=rHVZcGnOZTXTdNyZpLDvx1H+mk aKq4DxnV7wkGmHRSMnsjRWrIQIZOE4GJy/JpO0mVeAtfSVe2ds7qRZUkFz2NiaPNIqCsbgDq7KzrL xcajwbfHuq9LZDxh/F5cZdcS6Bb3F7MKoIB0LaFlyh8wK/B4SglAMnzEngvSOxdzHIHde24WlNqzx uI3Z3M/mv5BCXqWzj1fqdbTHlJ48sRzzcwYM4hgttr81dwzyOSv3wT/n5IOP+oPtG+rKmAraBM+1+ zVnQocUj82G2y5W0yvFnRawUldi+Wo+myH4Vzf992xB2GDAvSSjr9q9Upf7t7vureMOcPCXh65YqO lC9G0Bwg==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:36206 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <ietf@bobbriscoe.net>) id 1n1zFk-0002gw-Gk; Mon, 27 Dec 2021 23:18:01 +0000
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: tsv-art@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, draft-ietf-httpbis-priority.all@ietf.org
References: <163823172684.25092.12541395997867030932@ietfa.amsl.com> <CALGR9oZJKr_guJfP_QxhTcAjXCGDT+a-gJHjFfksFisc-ZAxnA@mail.gmail.com> <5a46e3d3-36b4-fde5-932f-0381bbe75e22@bobbriscoe.net> <CALGR9oYuuxNnFB+1XuN+gGJvpQsovhYWvMVhrioP69O-kKhKJA@mail.gmail.com> <136d9169-fd43-793c-f330-f2dd70fbf8ab@bobbriscoe.net> <CALGR9oa79fyeBBfgZp9ruNYi_GDOXv-6UMJN75OvLGwqiZN1Sw@mail.gmail.com> <8b131cf3-20c8-4438-fbf6-d23ab0f3d807@bobbriscoe.net> <CALGR9oadvcZ=ocxgqxhAVz4dNA8Ym9pWQoB7+3LELgPFQjFHaA@mail.gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <4d760c6a-4d33-61ad-42aa-832141b3ce90@bobbriscoe.net>
Date: Mon, 27 Dec 2021 23:18:00 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <CALGR9oadvcZ=ocxgqxhAVz4dNA8Ym9pWQoB7+3LELgPFQjFHaA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------0013FAC848DCE6EE61D74C0F"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/3Mwyy_FFRpRA11vKz8xnI5KwdM8>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-httpbis-priority-10
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Dec 2021 23:18:24 -0000
Lucas, BTW, no need to treat me as a blocking approver for PRs. I'm raising points as a reviewer outside the WG, and just expect you and the WG to want to fix stuff if you collectively think it is needed. But I am persisting on points where I think I've been misunderstood. See [BB4] inline... On 24/12/2021 14:08, Lucas Pardue wrote: > Hey, > > Responses as LP3 from me :-) > > On Fri, Dec 24, 2021 at 9:58 AM Bob Briscoe <ietf@bobbriscoe.net > <mailto:ietf@bobbriscoe.net>> wrote: > > Lucas, see [BB3] > > On 24/12/2021 01:37, Lucas Pardue wrote: >> Hey Bob, >> >> Responses in line, I used LP2 just to aid navigation >> >> On Thu, Dec 23, 2021 at 4:29 PM Bob Briscoe <ietf@bobbriscoe.net >> <mailto:ietf@bobbriscoe.net>> wrote: >> >> Lucas, >> >> I'm trying to close down as many of my points as I can. But >> still hanging on with some... see [BB2]... >> (BTW, I'm not subscribed to any w3.org <http://w3.org> lists, >> so it's blocking my responses. I think that's OK, 'cos so far >> you've not snipped any quoting.) >> >> On 21/12/2021 18:16, Lucas Pardue wrote: >>> Hey Bob, >>> >>> Responses inline (tagged [LP] because my mail client decided >>> to be weird today) >>> >>> On Tue, Dec 21, 2021 at 12:16 PM Bob Briscoe >>> <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote: >>> >>> Lucas, >>> >>> Thanks. Responses tagged [BB] inline where necessary. No >>> comment = agreed/understood. >>> >>> Although I wrote this on 10 Dec, I held back from >>> sending in order to think about fairness, but then >>> forgot to finish it. I hope the extra time stewing has >>> been worth it. I haven't gone back to all the issue >>> trackers since then, except the one on fairness. >>> >>> Altho' you ack'd receipt of my updated review, I notice >>> you've responded to the original incorrect one. >>> So I've added back in my corrections and clarifications, >>> tagged [BB-follow-up], because they toned down some of >>> my snottiness, which I was trying to retract. >>> >>> >>> On 09/12/2021 15:43, Lucas Pardue wrote: >>>> Hi Bob, >>>> >>>> Thanks (again) for the review. >>>> >>>> We've been working through the editorial issues and >>>> have cut release -11 to address the ones we agreed >>>> with. Responses to the technical issues you presented >>>> are in-line below: >>>> >>>> On Tue, Nov 30, 2021 at 12:22 AM Bob Briscoe via >>>> Datatracker <noreply@ietf.org >>>> <mailto:noreply@ietf.org>> wrote: >>>> >>>> Reviewer: Bob Briscoe >>>> Review result: Almost Ready >>>> >>>> This document has been reviewed as part of the >>>> transport area review team's >>>> ongoing effort to review key IETF documents. These >>>> comments were written >>>> primarily for the transport area directors, but are >>>> copied to the document's >>>> authors and WG to allow them to address any issues >>>> raised and also to the IETF >>>> discussion list for information. >>>> >>>> When done at the time of IETF Last Call, the >>>> authors should consider this >>>> review as part of the last-call comments they >>>> receive. Please always CC >>>> tsv-art@ietf.org <mailto:tsv-art@ietf.org> if you >>>> reply to or forward this review. >>>> >>>> Version reviewed: >>>> Originally draft-ietf-httpbis-priority-09, but also >>>> checked -10 diff. >>>> >>>> ==Summary== >>>> The move to an e2e request and hop-by-hop response >>>> is a good one. >>>> >>>> I'm not sure how ready this is, until I see how the >>>> authors respond to my >>>> questions about the interaction model and whether >>>> the client can say "I dunno, >>>> you tell me" to the server (T#4c, T#5a and T#9a). >>>> >>>> I think all of my other points are 'just' holes in >>>> the coverage of each aspect >>>> of the protocol, but some will be quite involved to >>>> fill. There's a lot of >>>> vagueness still to be tied down, I'm afraid. >>>> >>>> Three sets of comments below: >>>> * Gaps (G#): 2 >>>> * Technical points or suggested modifications to >>>> normative text (T#) 13 >>>> * Editorial points (E#) 29 >>>> >>>> ______________________________________________________________ >>>> ==Gaps== >>>> >>>> G#1 Implementation status section? >>>> >>>> This review would have really benefited from an >>>> implementation status section. >>>> You will see I got suspicious that some of the >>>> sections had been written >>>> without the benefit of any implementation or >>>> operational experience. While >>>> others seemed stronger. If the implementation >>>> status had been written up, I >>>> wouldn't have had to guess. >>>> >>>> Here's my guesses at what has been implemented, >>>> given the waffle factor of the >>>> relevant sections ;) >>>> >>>> [BB-follow-up]: Sorry, 'waffle factor' was a >>>> bit derogatory. I meant that the sections that >>>> I have identified below as 'less mature' tended >>>> not to say anything significant, while >>>> apparently looking as if they were saying >>>> something significant. >>>> >>>> >>>> * e2e priority protocol protocol handlers and >>>> schedulers: most mature >>>> >>>> * intermediary priority protocol handlers and >>>> schedulers: not so mature >>>> >>>> * automated priority header generation, APIs: not >>>> so mature >>>> >>>> * priority of server push, retransmissions, probes: >>>> just ideas in theory? >>>> >>>> * investigation of deadlocks, loops, etc: early days. >>>> >>>> >>>> The short answer is that HTTP prioritization is much of >>>> an optional thing. Signals are hints to the server in >>>> charge of the multiplexed connection. Servers have a >>>> self-interest in serving requests in a timely manner >>>> balanced against all the other needs like resource >>>> usage, DoS avoidance and so on. The sections that >>>> describe scheduling are some basic recommendations that >>>> will let clients have some expectations how responses >>>> would get prioritized should the stars align. But this >>>> is not a very specific algorithm that all >>>> implementations will follow exactly because rarely do >>>> stars align. The sections attempt to spell out the >>>> considerations arising from the protocols related to >>>> this draft. We believe the editorial changes made in >>>> -11 make it clearer where text is considerations more >>>> than authoritative direction on what to do. >>> >>> [BB] I think you might have missed my point. I meant a >>> section telling us what degree of implementation there >>> has been of each aspect (to be removed before >>> publication as an RFC). I should have referenced BCP 205 >>> [RFC7942]. >>> >>> Reason: Unless readers put in effort to track what >>> everyone else is doing, they have no idea whether the >>> various aspects of this draft are based on arm-waving or >>> real operational experience. For anyone who is >>> implementing themselves, that colours how much weight >>> they should give to the advice relative to their own >>> experience. >>> >>> >>> [LP] The nature of this spec means that the majority of the >>> work - server scheduling - is delegated solely to server >>> implementation detail. The considerations presented hold >>> whether people choose to take them into account or not. How >>> large an effect the considerations have on any single >>> implementation depends on the nature of the implementation, >>> the deployment environment, the runtime conditions under >>> which any single connection is operating, etc. >>> >>> Given where we are at in the document cycle, adding such a >>> section would just delay progress and I'm not convinced it >>> will improve this document for the target audience. >> >> [BB2] An implementation status section is most useful for >> reviewers; indeed it's recommended that it's deleted before >> publication. So I accept it would be a pain to add it just >> for the last few final reviews from the wider Internet >> community. But bear in mind that you have to get through the >> IESG as well. >> >> Whatever, hopefully you might consider one for future drafts. >> >> >> [LP2] I agree a record of interop and implementation status is >> useful for several purposes. I'll bear communication of status to >> reviewers in mind for future drafts. >> >> FWIW In the QUIC WG we have typically tried to record some >> results during hackathon events or Martin Seeman's hosted interop >> runner [1]. In the HTTP WG things are a bit different. Surveying >> implementation status of various HTTP features can be tricky, >> there's a few things like mnot's cache tests [2] or h2spec. >> >> >>> >>>> >>>> >>>> >>>> G#2 Performance evaluation? >>>> >>>> Priorities are about improving performance. This is >>>> a stds track draft about a >>>> core IETF protocol. But there is nothing in this >>>> draft pointing to any studies >>>> that quantify how much performance is improved (or >>>> not) by the different >>>> aspects of the protocol. Ideally there would be a >>>> study comparing the HTTP/2 >>>> priority approach with this one. Is that because >>>> the studies don't exist, or >>>> just an omission? >>>> >>>> [BB-follow-up]: I was wrong to say there is >>>> nothing pointing to any studies, just that the >>>> studies pointed to haven't been cited. I should >>>> have just asked for references to be provided >>>> at the end of §2, after: >>>> >>>> "Multiple experiments from independent >>>> research..." >>>> >>>> >>>> We simply overlooked citing them, which was noted in >>>> other reviews. We added links to work from Robin Marx >>>> and Pat Meenan that motivated this document and it's >>>> design features. >>> >> >> [BB] I've now read the two references you added. I think only >> [MARX] fits after "Multiple experiments from independent >> research". [MEENAN] is more of an explanation of the problem >> (not the problem with 7540, but the problem of not having a >> prioritization protocol at all). And it is not really >> intended to be scientific research - the only quantified >> improvement is "We have seen 50% faster on multiple >> occasions" - there are no specific experiments or results. If >> you want to keep it, it could be added at the end of the >> first para of the Intro, perhaps. But you might find the RFC >> Editor cuts it out, because it is not an archival reference >> (it's a blog). >> > > [BB3] Sry, I should have tagged the above as [BB2], which is > probably why you missed it. > > > [LP3] The experiment is in replacing wholesale the RFC 7540 tree-based > prioritization with the scheme diagramed mid-way down the page. This > continues to operate and meets the criteria of the sentence fragment > "simpler schemes can reach at least equivalent performance". I accept > that this is not of the rigor of a scientific paper and I can remove > it if it's a weak citation or distraction. The important link is that > the work and the scheme were part of the original motivation for > Extensible Priorities work but we capture that in the acknowledgements > already. [BB4] I'll leave you to decide what to do with [MEENAN]. BTW, I don't think one example with conveniently sized objects counts as proof of "at least equivalent performance". > > > >> >>>> >>>> ______________________________________________________________ >>>> ==Technical Points and Modifications to Normative >>>> Statements== >>>> >>>> §2. Motivation for Replacing RFC 7540 Priorities >>>> >>>> T#2a) Grass is always greener on the other side of >>>> the fence? >>>> >>>> RFC 7540 priority is expressed relative to other >>>> requests on the same >>>> connection. Many requests are generated without >>>> knowledge of how >>>> other requests might share a connection, which >>>> makes this difficult >>>> to use reliably >>>> >>>> This says why relative values were difficult, but >>>> it doesn't say why or whether >>>> absolute values will be better. Is there lots of >>>> experience of absolute values >>>> being sufficient and easier to use? or any cases >>>> where absolute values might be >>>> insufficient? It seems obvious that at run-time you >>>> might hit the end of the >>>> number space, i.e. have to pile up objects on the >>>> same urgency value at the >>>> edge of the space when you really wanted some >>>> objects to have higher (or lower) >>>> urgency. There is a mention of the possibility of >>>> creating an extension with >>>> intermediate urgency values, but what does an >>>> implementation do when it hits >>>> this problem in the middle of a session? It can't >>>> quickly jump out of run-time, >>>> convene a design team to get a new scheme extension >>>> agreed then go back to >>>> run-time and complete the session. >>>> >>>> >>>> Dependencies between the requests in a connection are a >>>> property of the connection. This poses challenges to >>>> acting on priority signals when passing them to >>>> components/nodes that are not part of the connection. >>>> That's friction against some ways that HTTP commonly >>>> operates in practice. For example, intermediaries or >>>> servers that split or coalesce requests from different >>>> connections. The urgency and incremental parameters >>>> have been deemed sufficient for a web browsing use >>>> case, which was our focus, without being too fine >>>> grained and hard for developers to reason about. If >>>> other use cases encounter limitations or problems with >>>> this scheme, I do encourage them to bring that back to >>>> the HTTP WG so we can consider work on extensions that >>>> address them. >>>> >>>> >>>> T#2b) Motivation for replacing 7540 included >>>> removal of dependencies? >>>> >>>> The Security Considerations says that one of the >>>> motivations for replacing 7540 >>>> was that "Extensible priorities does not use >>>> dependencies, which avoids these >>>> [resource loop DoS attack] issues." Draft-09 listed >>>> this as one of the >>>> motivations in §2, but in draft-10 it has been >>>> removed from §2. If it is still >>>> a motivation, it ought to be listed in §2, not just >>>> in Security Considerations. >>>> >>>> Security Considerations seems to be in the commonly >>>> used style of just a list >>>> of pointers to other parts of the draft. So it >>>> would be consistent to say this >>>> in §2 not just in Security Considerations, which >>>> even says "Considerations are >>>> presented to implementations, describing how..." as >>>> though the details are >>>> elsewhere in the document. >>>> >>>> Whatever, given this seems to have been an >>>> important motivation, please try to >>>> describe this issue in a self-contained way, rather >>>> than talking obliquely in a >>>> way that requires the reader to refer to the CERT >>>> advisory (e.g. "...some types >>>> of problems..."). >>>> >>>> >>>> The text was written before the 7540bis activity >>>> started. We’ve been shifting bits and pieces of RFC >>>> 7540 problems to that venue. This one has been removed >>>> since it seems like a distraction for the topic of this >>>> document. >>> >>> [BB] I notice it's now removed from Sec Consids as well. >>> >>> That's fine, but BTW, it wasn't a distraction for me. It >>> seemed to be one of the stronger reasons for moving away >>> from dependencies, because (in many cases) I can't >>> understand how priorities can be implemented without >>> knowing the dependencies (see T#9a). >>> >>> >>> [LP] Ack. We think the text in the latest version now pays >>> enough detail to RFC 7540 without treading on 7540bis toes. >>> >>> >>>> >>>> §2.1. Disabling RFC 7540 Priorities >>>> >>>> T#2c) Incremental deployment >>>> >>>> Two perhaps obvious but unstated things ought to be >>>> stated: >>>> i) An HTTP session will always _function_ even if >>>> all priority information is >>>> ignored; it just might perform badly. >>>> >>> >>> [BB] I think you've overlooked this point. >>> >>> In your very first response above - about implementation >>> status - you say "The short answer is that HTTP >>> prioritization is much of an optional thing." The point >>> I was making here is that I don't believe the draft ever >>> actually explicitly says the obvious - that HTTP will >>> function without any priorities at all. And even if the >>> lack of MUSTs ultimately implies everything is optional, >>> it would be worth making that clear from the outset in >>> the Introduction. >>> >>> BTW, when I asked for the refs to evaluations, I was >>> trying to establish whether the gain from prioritization >>> is turning out to be worth the pain of implementing it >>> and driving it at run-time. >>> >>> >>> [LP] HTTP/2 and HTTP/3 (and QUIC) are the protocols that >>> define mulitplexing and concurrency and they contain >>> comments roughly equating to prioritization is good, no >>> prioritization is bad. Neither 7540bis, RFC 9000 or >>> draft-ietf-quic-http-34 define prioritiy signals. >>> >>> Can you elaborate on what problem is solved by adding the >>> statement you suggest to this document? >> >> [BB2] An initial implementation can discover that they can >> defer reading the spec until later; without having to read it >> to find out they didn't have to. >> >> >> [LP2] Priority signaling and prioritization of concurrent >> resources are different things. A server implementer has to think >> about prioritization independent of RFC 7540 priority signals or >> Extensible priority signals. The introduction states what clients >> and servers can do, especially that servers can do whatever they >> like. The only thing I can think to suggest for this point is >> modifiying Section 1 paragraph 3 to say something like "HTTP/2 >> and HTTP/3 servers can schedule transmission of concurrent >> response data by any means they decide. Servers can ignoring >> client priority signals and still successfully serve HTTP. >> However, servers that operate in ignorance of clients >> ...<reamining text>" >> >> If that sounds reasonable I'll open a PR. But if you're looking >> for some other type of statement that labours the point about >> HTTP working without signals, then I don't think we need it here >> because its covered elsewhere. > > [BB3] It doesn't also say that clients don't need to send priority > signals, but it's better than it was. Esp. if you can > s/servers/servers or intermediaries/ in both the new sentences. > Thank you. > Also s/can ignoring/can ignore/ > > > [LP3] Thanks, see https://github.com/httpwg/http-extensions/pull/1871 > <https://github.com/httpwg/http-extensions/pull/1871> [BB4] OK. > > >> >> >> >>> >>> >>>> >>>> ii) The semantics of the >>>> SETTINGS_NO_RFC7540_PRIORITIES setting is intended to >>>> apply to both directions (if it is?). When it says >>>> "A server that receives >>>> SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 MUST >>>> ignore HTTP/2 priority signals." >>>> I assume after "MUST ignore" it intends to add >>>> "...and MUST NOT send...". >>>> >>> >>> [BB] I don't think you've addressed this point below or >>> in the linked issue you've opened. Altho there is no >>> appetite in the WG for defining what 7540 should have >>> said, surely it would be worth closing off any >>> uncertainty for the future, given all the opinions in >>> response to this point were purely based on what they >>> /think/ has not been implemented. It would do no harm to >>> just add that a 7540bis server in receipt of >>> SETTINGS_NO_RFC7540_PRIORITIES =1 MUST NOT send HTTP/2 >>> priority messages (as well as ignoring incoming). >>> >>> >>> [LP] Other documents talk in terms of servers operating on >>> client signals. They don't mention server->client PRIORITY >>> frames. So in effect, the signal is always ignored anyway. >>> Trying to talk to that direction of flow of the signal here >>> seems like it would add complication to the document and I >>> think a distraction. >>> >>> If there is some use of server->client signals, then the >>> HTTP WG is not aware of it. If the people that use >>> server->client signals feel like they need to disable them, >>> then then I think they are best placed to document the >>> concerns for that. >>> >>> >>>> I assume this is stated as "server MUST ignore" >>>> rather than a protocol error, >>>> because the HTTP/2 priority signals might have come >>>> from an intermediary that >>>> doesn't understand the >>>> SETTINGS_NO_RFC7540_PRIORITIES setting. >>>> >>> >>> [BB] This was a question really. The subsequent points >>> depend on the answer. >>> >>> If the answer is that HTTP/2 priority signals could >>> never arrive at the server from an intermediary, and if >>> a client says it won't send a certain header, but >>> subsequently the server receives one anyway, surely that >>> is a strong case for protocol error. >>> >>> >>>> >>>> Also, it is surely a protocol error if one endpoint >>>> sets >>>> SETTINGS_NO_RFC7540_PRIORITIES to the opposite of >>>> the other. >>>> >>> >>> [BB] I don't think you've addressed this point either. >>> What is meant to happen if >>> * an HTTPbis client sends SETTINGS_NO_RFC7540_PRIORITIES = 1 >>> * the HTTPbis server sends >>> SETTINGS_NO_RFC7540_PRIORITIES = 0 >>> ? >>> >>> This means the client is "not using" HTTP/2 priority >>> signals and the server says I "won't ignore" HTTP/2 >>> priority signals I receive. Altho' that would lead to no >>> protocol problems, doesn't it imply that the server is >>> somehow broken? I agree that the old HTTP/2 priority >>> signals are hints, but this SETTINGS message is not a >>> hint. It's a configuration setting introduced in >>> HTTPbis. So isn't it worth defining it fully? >>> >>> >>>> Or if a node sends >>>> a header after it has said it won't. >>>> >>> >>> [BB] Again, this relates to the new SETTINGS message, >>> not the fact that 7540 priority messages are hints. >>> Surely errors like this need to be caught (they could >>> e.g. be due to a load balancer switching to an endpoint >>> with a different config). >>> >>> >>> [LP] Responding to the three points as one: >>> >>> Given the current constrains and how loosely coupled things, >>> I'm not sure what problem is solved by a protocol error. >>> >>> H2 says - "Settings are not negotiated; they describe >>> characteristics of the sending peer, which are used by the >>> receiving peer.". And that governs a lot of what this >>> section can do. >>> >>> The initial value of SETTINGS_NO_RFC7540_PRIORITIES is 0. A >>> client that understands the setting will assume 0 when >>> SETTINGS arrive and SETTINGS_NO_RFC7540_PRIORITIES is not >>> present. So the client=1, server=0 case exists already >>> implicitly. >>> >>> One likely deployment model for the Extensible priorities >>> scheme is for HTTP applications to add the priority header >>> on request messages, in ignorance of whatever the HTTP stack >>> underneath supports or is doing. That lets them write >>> version-independent logic. Being too strict with settings >>> rules risks adding hard-to-diagnose errors for such >>> applications. >>>> >>>> >>>> If a client sets SETTINGS_NO_RFC7540_PRIORITIES to 1, >>>> but the server doesn't >>>> understand this setting, and later sends HTTP/2 >>>> priority signals (perhaps in >>>> response to an intermediary), what happens? >>>> >>>> [As I pointed out in my review of >>>> RFC7540 Priorities (when it was a draft but after IESG >>>> approval), it wasn't >>>> clear whether priority messages were only sent in the >>>> C-S direction, or also >>>> the reverse. I didn't receive a reply on that point and >>>> the RFC is still not >>>> clear. >>>> https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0529.html >>>> <https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0529.html> >>>> ] >>>> >>>> [BB-follow-up]: That wasn't intended to sound like >>>> sour grapes. In the opening sentence of my review >>>> of http/2 I had said I was aware that my (long) >>>> review had arrived after http/2 had been approved >>>> by the IESG. My review was unsolicited. And I guess >>>> the last thing anyone wants to do when their draft >>>> has just been approved is answer a load of points >>>> about something they are not going to change. But I >>>> guess it should have been handled eventually, if >>>> only for errata. >>>> >>>> >>>> Francesca also mentioned this in the AD review. RFC750 >>>> seems to have allowed server-to-client signals on the wire >>>> but didn’t specify what at all anyone should do with them. >>>> I’m not aware of any cases of this signal being used in the >>>> wild. I created an issue on >>>> https://github.com/httpwg/http2-spec/issues/1000 >>>> <https://github.com/httpwg/http2-spec/issues/1000> there's >>>> further discussion there. 7540bis deprecates stream >>>> prioritization - all that is left is the remnant of bits on >>>> the wire that remain for wire compatibility. >>>> >>>> SETTINGS_NO_RFC7540 is an optimization related to carriage, >>>> processing and application of signals. Because these >>>> signals are only a hint, as long as they have a valid wire >>>> format there is no need for protocol errors. Since we are >>>> focused on C->S direction of signal, and the world never >>>> defined what RFC7540 S->C signals really meant, our >>>> document doesn’t benefit from trying to speak about them. >>>> So we define our terms of use in the Notational Conventions >>>> and stick to them. The document consistently uses this term, >>> >>> [BB] Above, I have highlighted again those of my points >>> that were about how the SETTINGS message itself (not the >>> 7540 hints) is not fully tied down. >>> >> >> [BB2] I'll stop harping on about SETTINGS_NO_RFC7540 now. I >> clearly don't understand the subtleties of http incremental >> deployment. >> >>> >>>> >>>> §4. Priority Parameters >>>> >>>> T#4a) Vagueness permeates what intermediaries do in >>>> this draft >>>> >>>> Intermediaries can consume and produce priority >>>> signals in a >>>> ...PRIORITY_UPDATE frame or Priority header field. >>>> ...Replacing or adding a Priority header field overrides >>>> any signal from a client and can affect >>>> prioritization for all >>>> subsequent recipients. >>>> >>>> * Do intermediaries really both consume and produce >>>> priority signals. Always? >>>> In both directions? What does 'consume' mean (absorb >>>> and not forward, or read >>>> and forward)? >>>> >>>> >>>> They can according to HTTP Semantics. >>>> >>>> >>>> * Can they really use either type of frame? Always? >>>> >>>> >>>> They can, it depends on the versions of HTTP being used on >>>> the upstream or downstream. >>>> >>>> >>>> * How does adding a priority header override any signal >>>> from a client? Or is it >>>> only replacing that overrides? >>>> >>>> My later comment asking for a more precise statement of >>>> the protocol's >>>> interaction model ought to resolve these issues as well. >>>> >>>> >>>> it all depends on the model about how HTTP intermediaries >>>> convert between versions. Frames are connection-level and >>>> headers might be e2e or hop-by-hop. This document shouldn’t >>>> litigate any more than it does on the matter. >>>> >>>> >>>> T#4b) Really only C-S direction? >>>> >>>> PRIORITY_UPDATE frame preserves the signal from the >>>> client, but... >>>> >>>> ...overrides any signal from a client... >>>> >>>> Also used for S-C direction? >>>> >>>> Given this part of the draft seems to have been written >>>> solely about the C-S >>>> direction, perhaps it would be better to admit that is >>>> a good way to structure >>>> the draft with C-S first. Then add another section >>>> about S-C, and perhaps >>>> another about S-Int. The alternative of adding to all >>>> the definitions to cover >>>> all directions and interactions, might become >>>> incomprehensible. >>>> >>>> >>>> This is different from HTTP/2 PRIORITY frames (as mentioned >>>> above). By definition PRIORITY_UPDATE is only allowed in >>>> the C->S direction, which eliminates the need to document >>>> the reverse direction. >>> >>> [BB] Then this becomes just an editorial point, that it >>> would be useful to say explicitly at the start of §4. >>> >>> CURRENT: >>> >>> PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) are used by >>> clients... >>> >>> PROPOSED >>> >>> PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) are sent by >>> clients (not by servers)... >>> >>> >>> There seems to be a pattern developing (RFC7540 and now >>> here) where the people who write the spec know what the >>> interaction model is and they assume everyone else does, >>> which sometimes becomes revealed implicitly as the >>> reader gets into the details, rather like a game of >>> Cluedo. It would be really, really helpful if you just >>> stated it early on. >>> >>> >>> The useful change is to clarify it's the client that sends >>> the frames. I made >>> https://github.com/httpwg/http-extensions/pull/1866 >>> <https://github.com/httpwg/http-extensions/pull/1866> to do >>> that. Stating client (not server), server (not client) is >>> not a style that I think would improve the readability of >>> this draft. >> >> [BB2] Thanks for the change you have made. >> >> You say "By definition PRIORITY_UPDATE is only allowed in the >> C->S direction". By what definition? It is not in the draft. >> Here are two places where you might think it is defined: >> >> §4 In order to reprioritize a request (Section 6 <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority#section-6>), HTTP- >> version-specific PRIORITY_UPDATE frames (Section 7.1 <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority#section-7.1> andSection 7.2 <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority#section-7.2>) >> are used by clients to transmit the same information on a single hop. >> >> §7 PRIORITY_UPDATE frames are sent by clients on the control stream, >> allowing them to be sent independent from the stream that carries the >> response. >> >> >> When I read the §4 sentence, I thought it might mean that >> servers could respond with a PRIORITY_UPDATE to their >> original priority message, but that it only mentions the >> client's update because it is newly defined for a single hop, >> while the server's was already hop-by-hop. >> >> The §7 sentence merely says which stream a PRIORITY_UPDATE >> should be on if it's in the C->S direction. Indeed, it could >> be read as if it also implies that responses will carry a >> PRIORITY_UPDATE frame on the relevant stream itself, not on >> the control stream. Given this protocol is extensible, why >> shouldn't a server be able to update a previous priority >> message? Will intermediaries ignore such a message? Must they? >> >> In this draft, it has not been considered necessary to >> explicitly state the interaction model. So valid interactions >> only appear implicitly in sentences that are primarily there >> to say something else. This is an extensible protocol, so the >> designers of extensions that want their new message to be >> consumed by a particular type of node are entitled to think >> that they can define it, unless this draft specifically >> precludes it. >> >> So, I beg to differ about negatives - they remove ambiguity. >> Absence of any statements about a frame in the S->C direction >> does not define that it is not used in that direction. And >> anyway, to find an absence the reader has to carefully check >> the whole draft (like Cluedo). This is the antithesis of >> improved readability. >> >> >> [LP2] Section 7.1 and 7.2 both include the statement that only >> you're looking for. 7.2 is the stronger of these, we can update >> 7.1 to match it (I think that was an editorial oversight, fixed >> by https://github.com/httpwg/http-extensions/pull/1869 >> <https://github.com/httpwg/http-extensions/pull/1869>). >> >> From section 7.2 para 8 >> >> PRIORITY_UPDATE frames of either type are only sent by clients. >> If a client receives a PRIORITY_UPDATE frame, this MUST be >> treated as a connection error of type H3_FRAME_UNEXPECTED. >> >> So by this definition, there is no way for a server to >> successfully send a PRIORITY_UPDATE frame. We could probably >> hammer this home more upfront in section 4 with an editorial >> tweak but it doesn't change the current design of the document. >> >> My comment about readability is in response to understanding >> whether you want X (not Y) on every instance. That seems overly >> wordy to me. If the suggestion was more geared around surfacing >> the constraint succinctly front and center, I'm more willing to >> consider it. I'll note even documents like >> draft-ietf-httpbis-semantics [4] don't seem to be trying to tie >> themselves in knots about stating only clients (not servers) send >> requests and only servers (not clients) send responses. > > [BB3] The recent changes have fixed and will fix this for > PRIORITY_UPDATE. The 'X (not Y)' formulation was only a suggestion > of how you might express this. Thanks. > > > [LP3] Cool. > > >> >> >> >> >>>> >>>> §4.2. Incremental >>>> >>>> T#4c) Client doesn't always have prerequisite info to >>>> set incremental parameter >>>> >>>> There will surely be cases where the MIME type of the >>>> response (and therefore >>>> whether the client can render it incrementally) is not >>>> known, or cannot be >>>> guessed by the client when it requests a resource, or >>>> when it starts content >>>> negotiation? For instance, the client might have listed >>>> MIME types in its >>>> Accept list, some of which are incremental, and some not. >>>> >>>> [BB-follow-up]: I intended to add that I suspect in >>>> common cases the client's guess of what MIME type >>>> is likely to served will be sufficient and correct. >>>> This comment was meant to be about the remainder of >>>> cases. >>>> >>>> >>>> >>>> The server can't override a client 'not incremental' >>>> message by stating that >>>> the MIME type it has served is incremental. Because, >>>> when the client says 'not >>>> incremental', that is intended to state the capability >>>> of the client, not the >>>> format of the resource. >>>> >>>> Perhaps the HTML that gave the client the hyperlink >>>> that was selected to get >>>> the resource could also include a tag giving the MIME >>>> type of the hyperlinked >>>> resource? Or perhaps the idea is that the client has to >>>> send a PRIORITY_UPDATE >>>> once it knows the MIME type (by which time it might be >>>> too late)? >>>> >>>> >>>> That's a fair point. Unfortunately, there will be cases >>>> where parties lack all of the information that could lead >>>> to perfect prioritization. Client priority signals are only >>>> a hint. Servers can and will do whatever they like, >>>> including serving the response in a way that does not >>>> follow the recommendations we provide for handling the >>>> incremental parameter in Section 10. There’s lot of >>>> additional means, outside of this specification, that >>>> clients and servers can use to augment their understanding >>>> of priority. There is no need to enumerate them in this >>>> document. >>> >>> [BB] Strictly then, the incremental parameter is a >>> property of each MIME type in the Accept list, rather >>> than a property of the request as a whole. But I guess >>> it is a reasonable assumption that most of the commonly >>> used selections of alternative MIME types will all share >>> the same incremental property. >>> >>> [LP] Ack. I think what we have is ample enough. >>>> >>>> >>>> §5. The Priority HTTP Header Field >>>> >>>> T#5a) Interaction model: an example or mandatory? >>>> >>>> It would help to start by explaining (perhaps in the >>>> Intro, rather than §5) >>>> whether a priority message about a response can be >>>> initiated by a server or >>>> intermediary if there was not a priority field attached >>>> to the request from the >>>> client. I believe the draft intends this not to be >>>> possible, although this is >>>> not stated normatively anywhere, and I don't know why >>>> such a restriction would >>>> be imposed. >>>> >>>> Actually, I believe it is essential that the protocol >>>> allows the server to >>>> initiate priority messages, as absence of a message is >>>> currently the only way >>>> for the client to say "I have no idea, you decide". >>>> Otherwise, if the server is >>>> only allowed to follow the client, when the server >>>> knows the best order to >>>> serve the objects (which I believe is often the case), >>>> the client still has to >>>> request non-incremental objects in some order or other, >>>> and give them some >>>> priority or other. So the server doesn't know whether >>>> the client actually knows >>>> what it is doing, or whether it is just making up an >>>> ordering because it has >>>> to, even tho' it has no clue. >>>> >>>> [BB-follow-up]: When I said "which I believe is >>>> often the case" I didn't intend to mean the >>>> majority of cases. I meant "not an insignificant >>>> number". >>>> I'm sure the client can have a crack at how to set >>>> the priorities in common cases. Which can then be >>>> modified by the server if necessary. >>>> >>>> The point I was trying to highlight was that the >>>> client has no way to tell the server how to >>>> distinguish between "I'm certain about these >>>> priorities" and "I'm not really sure, but the >>>> protocol requires me to look as if I'm sure, even >>>> if I just leave everything as default priority." >>>> I think I explained it better under T#9a. >>>> >>>> >>>> Alternatively, could the client send a Priority header >>>> with no parameters? This >>>> would indicate that the client wants the server to >>>> prioritize, and to allow the >>>> server to tell intermediaries what to prioritize. (For >>>> more about clueless >>>> clients, see T#9a) "Client scheduling".) >>>> >>>> The abstract gives the only outline of the interaction >>>> model, but it's not >>>> clear whether this is just an example of common usage, >>>> or the only possible >>>> model. >>>> >>>> §5 just says the priority field can be used "when a >>>> request or response is >>>> issued". It goes on to state that the priority field is >>>> an e2e signal, but then >>>> in the next sentence talks about how intermediaries can >>>> combine priority info >>>> from client requests and server responses (which >>>> reflects what §8 says as >>>> well). So "e2e" is clearly an over-simplification. I >>>> think it's e2e in one >>>> direction but hop-by-hop in the other (supported by the >>>> description in the >>>> abstract), ie. client -> server -> intermediary/ies -> >>>> client. It's also >>>> possible that intermediaries are intended to (or at >>>> least allowed to) read but >>>> do not alter the messages in the C-S direction, >>>> otherwise, what would they >>>> 'combine' with the priority field coming from the other >>>> direction? >>>> >>>> Whatever, the interaction model(s) is never stated >>>> precisely. I've classified >>>> this as a technical point, not just editorial, because >>>> I couldn't really assess >>>> the completeness of many other technical details of the >>>> draft without knowing >>>> the answer to this fundamental question. >>>> >>>> >>>> If this scheme is implemented at the server, then all >>>> requests are treated as if they have an associated priority >>>> signal. This can be a Priority header field (Note the >>>> serialization rules for Structured Fields Dictionary in >>>> Section 3.2 of RFC 8941 - sending an empty header is not >>>> permitted) or a PRIORITY_UPDATE frame. Omission of signals, >>>> or omission values in signals, invokes default value >>>> priority parameters urgency=3, incremental=false. A server >>>> is therefore able to determine the client’s view of the >>>> priority. >>>> >>>> Editorial changes now in Section 10 should make it clearer >>>> that an HTTP server’s job is to respond in a timely manner. >>>> And it always has to decide how to use finite resources to >>>> do so. Clients can hint as some preference but if they >>>> don’t know or don’t care, it's basically delegating the >>>> responsibility to the server. >>>> >>>> The purpose of the Priority header in responses is to allow >>>> origin servers (detached from the intermediaries’ >>>> connection to the client) the ability to also provide hints >>>> about prioritization. >>>> >>>> The interaction model is described throughout the document, >>>> with a gist in the intro. Duplicating details into the >>>> intro does not seem beneficial. >>> >>> [BB] This is a major problem for the reader. All the way >>> through, I'm having to build a set of possibilities of >>> what might be meant, then gradually remove them one at a >>> time, which is why I likened it to a game of Cluedo. >>> >>> An interaction model is never about 'details'. I'm not >>> asking for details. I'm asking that, if the model >>> described in the abstract is the only model, it says so. >>> And if it's only an example, it says so. It is a common >>> mistake for the authors of a protocol to omit >>> description of the big picture, probably because there >>> has never been any other possibility of a different big >>> picture in /their/ minds. >>> >>> >>> [LP] In that case, I don't really follow what you're asking >>> for. We note the actors and the messages between them. Just >>> adding a sentence to Section 1 of paragraph 6 that says "the >>> only thing we've defined applies to the only this we've >>> defined" seems like waffle to me. Maybe you have a better >>> concrete suggestion? >> >> [BB2] I would say the most relevant place to do this would be >> to limit extensibility. Otherwise the interaction model could >> be read as just the one needed for the parameters defined so >> far. So, straight after the last sentence of §3: >> >> Such extensions can >> define themselves how this priority scheme is to be applied. >> >> Add: >> >> However, they have to {MUST?} keep to the same interaction model where >> the client sends an end-to-end Priority field to the origin server >> and the server sends hints in the Priority field to downstream >> intermediaries, or the client sends hop-by-hop PRIORITY_UPDATE frames >> to intermediaries. >> >> >> BTW, I notice the sentence below from §4 says that the >> Priority field is e2e in both directions, so I think it will >> need to be corrected to say hop-by-hop in the S->C direction. >> >> The Priority HTTP header field (Section 5 <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority#section-5>) is an end-to-end way to >> transmit this set of priority parameters when a request or a response >> is issued. >> > > [BB3] I think your response below overlooked the 'BTW' editorial > point above. > >> [LP2] I hope the response to the prior point transfers a bit >> here. I don't see how extensions can change the interaction model >> we define unless they wish to extend it. In which case why would >> we have anything to say here about what they extend it to do? > > [BB3] You say "the interaction model we define". It is now defined > for PRIORITY_UPDATE. But, still labouring my point, for the > Priority header, the interaction model is not /defined/. Some > interactions are mentioned. But the the set of allowed > interactions is not defined normatively. > > If the interaction model is defined well, it can be narrowed but > not widened by extending a parameter. For instance, if an > intermediary is not meant to look at an end-to-end Priority field > in one direction, no-one can add an extension parameter within a > Priority field in that direction that is intended for an > intermediary. > > But if the interaction model is unclear (as it still is for the > Priority header), you get the sort of discussions like we had > about the SETTINGS as to whether some implementations might have > interpreted a vague interaction model (RFC7540 in this case) in a > different way to how it was intended. > > This is why an interaction model is primarily about which > interactions are /not/ supported. > > > [LP3] Responding to both of these points. I'm not sure I understand > your interpretation of the header treatment here. The header is > end-to-end for both request and response. HTTP semantics defines the > interaction model for messages. HTTP allows intermediaries to do a lot > of things with the request and response messages that they forward. I > don't see the need to litigate HTTP semantics in this draft. > > The whole point of this statement you quote is to handle applicability > to HTTP/2 or HTTP/3 extensions that allow new data carriage mechanisms > that don't follow existing HTTP semantics. For example, > draft-ietf-masque-h3-datagram [1] defines how HTTP/3 endpoints can use > QUIC datagrams to send unreliable messages. Unreliable messages have > no HTTP semantic, so we don't have the means to predict how a priority > signal would be sent or the means to tell a server how it might > prioritize datagram data against response data. Defining such things > can be done by the extension if they care to do it - for example by > binding datagram flows to requests and stating how Extensible > priorities does or does not apply. But we can't predict the future, > which is why this draft shouldn't be overly restrictive for future uses. [BB4] It's fine not to be overly restrictive for future extensibility. I was under the impression that the abstract /was/ trying to restrict the possible interactions, and I was trying to help you define that interaction model more clearly. If you actually want to say "anything goes", then there is no interaction model to define. I think we've been talking past each other in a clash of inter-area terminology and culture misunderstandings. In the transport area, interactions are much more tightly tied down. In the transport area, even where 'any interaction' was the intended model, each possible interaction type would have to be exercised to check that 'any' really could mean 'any'. I was involved in HTTP/1.1 back in 1995, and my memory is of a similarly careful enumeration of all the ways headers could be handled by the intermediaries known at that time. But I guess the culture has moved on since then. I must now officially be an 'old fart'. > > > >> >> >>>> >>>> T#5b) Normative 'cannot'? >>>> >>>> Clients cannot interpret the >>>> appearance or omission of a Priority response header as >>>> acknowledgement that any prioritization has occurred. >>>> >>>> Was this intended to say 'Clents MUST NOT interpret...'? >>>> >>>> >>>> Signals by design are just a hint. They can never be >>>> trusted and this sentence highlights that fact. >>>> >>>> >>>> T#5c) Nothing said about caching and priority >>>> >>>> The paragraph about caching and priority just ends >>>> having talked a bit about >>>> caching but not about priority. It left me none the >>>> wiser about what a cache >>>> ought to store about priority with the response. §13.8 >>>> talks about fairness >>>> between multiple live connections in the presence of >>>> coalescing. But doesn't >>>> the discussion of caching and priority here need to >>>> talk about what >>>> must/should/may be stored about priority in a cache for >>>> later connections. Even >>>> if it's implementation dependent, wouldn't it be worth >>>> a brief discussion (as >>>> in the 2 paras below). >>>> >>>> The priority of a response is the outcome of an >>>> interaction between the >>>> client's original (e2e) priority combined with the >>>> server's logic about the >>>> resource. If only the priority outcome is stored, then >>>> when another request >>>> arrives at the cache from a different client, there >>>> will be no record of the >>>> original client's priority. So the cache will not know >>>> what client priority >>>> led to the priority stored with the response. And it >>>> will not know whether the >>>> current client priority is the same or different. >>>> >>>> On the other hand, if the cache stores the original >>>> client priority with the >>>> response priority, then should it refer a request with >>>> a different (e2e) client >>>> priority to the server, then store the new pair of >>>> priorities with the original >>>> cached response? And I guess it could serve the request >>>> in parallel, rather >>>> than waiting for the server to tell it whether to serve >>>> the request urgently >>>> (!). This would probably scale reasonably well, given >>>> the likely small number >>>> of different client priorities. But who knows how it >>>> would scale if the >>>> parameter space is extended in future. >>>> >>>> >>>> Answer supplied by Kazuho - As discussed in the last >>>> paragraph of section 5, CACHING defines if and how requests >>>> with different header field values can be mapped to one >>>> response. If the capabilities provided by CACHING (i.e. >>>> Vary) is too limited, then we should fix that as an >>>> extension to CACHING (as have been previously proposed as >>>> draft-ietf-httpbis-key).In practice, re Extensible >>>> Priorities, IMO, there aren't many sensible combinations of >>>> urgency and incremental. Therefore, backend servers that >>>> want to tune priority based on the value that the client >>>> sends can simply send Vary: priority and call it a day. >>> >>> [BB] I think my point has been missed. I'll try an example: >>> Client A requests >>> priority u=4 >>> Server responds >>> priority u=2, >>> which gets cached. >>> Client B requests same object >>> priority u=4. >>> Client C requests same object >>> priority u=0 >>> >>> If requests B & C were forwarded to the origin, it would >>> respond with >>> priority u=2 # for B >>> priority u=0 # for C >>> >>> However, even though the cached object has the same >>> priority header that the origin server would give to >>> Client B's request, it's different to that cached. And >>> the cache cannot tell that B's request would match, but >>> C's wouldn't. >>> >>> Vary doesn't help here, does it? At least not without >>> storing the client request priority as well as the >>> server response. >>> >>> >>> [LP] I'll let Kazuho respond to this one. >>>> >>>> >>>> §9. Client Scheduling >>>> >>>> T#9a) Client doesn't have prerequisite info about >>>> content sizes and dependencies >>>> >>>> Consider a web page example with a load of >>>> non-incremental objects for the >>>> client to request. It doesn't know their sizes, and it >>>> doesn't know which ones >>>> might contain references to further objects to request. >>>> So it requests A,B,C,D. >>>> In retrospect, it turns out that C was huge, and D >>>> referred to further objects >>>> to download. How was the client to know it should have >>>> downloaded D before C? >>>> >>>> To be effective, a scheduler needs to know object sizes >>>> and which objects will >>>> identify further objects to be requested (dependencies). >>>> * Size is known by the server but not by the client, at >>>> least not until the headers >>>> at the start of the object arrive. >>>> * Dependencies are known by the server, but not by the >>>> client until an object >>>> starts to unfold. >>>> >>>> Why is the client made to choose the priorities of the >>>> responses? It doesn't >>>> know any of this vital metadata about these objects. It >>>> can guess from file >>>> types that JS and HTML probably ought to come first. >>>> But it knows little else. >>>> >>>> So, as I already said under my question T#5a) about the >>>> interaction model, the >>>> most important capability the client must have is the >>>> ability to say "I dunno, >>>> you decide". But that's the one thing this draft >>>> doesn't allow the client to do >>>> (at least I think it doesn't? see T#5a). For a list of >>>> non-incremental objects, >>>> even if the client gives all their requests the same >>>> urgency, it can't send all >>>> the requests at the same time - it has to choose which >>>> order to send them in, >>>> even if it has no clue. This tells the server to >>>> respond in that order OR to >>>> choose a different order. But the server doesn't know >>>> whether the client chose >>>> this order deliberately or just because it didn't know >>>> any better. >>>> >>>> Alternatively, there will need to be some way for the >>>> server to tell the client >>>> what to prioritize _before_ it sends its requests (e.g. >>>> using extensions to the >>>> HTML in a base HTML document). >>>> >>>> >>>> As noted in response to T#4c, we are constrained by the >>>> capabilities of information exchange that HTTP and its uses >>>> (such as the web) allows us. This is no different a problem >>>> than existed for RFC 7540. Only a client knows how it wants >>>> to use resources for which it has limited knowledge. >>> >>> [BB] it's not the case that only a client knows how to >>> use resources... That's the whole problem. >>> The position is that B (the server) has to decide how to >>> prioritize, but B knows info that A needs in order to >>> tell B what to prioritize. And there's limited time for >>> them to chat about it before prioritization becomes moot. >>> >>> So either B tells A the missing info, so A can tell B >>> what to prioritize. Or A tells B its various strategies >>> that depend on the info B holds. The latter is complex, >>> the former would make more sense, but only if the >>> protocol exchange had started earlier (!) >>> >>> I think the new priority approach is deliberately not >>> fully solving this problem (unlike http/2 priorities), >>> on the basis that httpbis can still add benefit for the >>> current typical way web objects are structured. If you >>> agree, I this is true, the spec ought to say it (nothing >>> to be ashamed about). >>> >>> >>> [LP] RFC 7540 didn't have a solution to this. The >>> information available to clients is independent of the >>> scheme used to signal a priority hint from client to server. >>> >>> In the "I dunno" case for RFC 7540, the defaults are invoked >>> (non-exclusive dependent on stream 0x0, weight 16) [1]. So >>> all requests had an implicit or explicit priority; an >>> explicit prioritization to stream 0x0 with weight 16 is >>> indistinguishable from an implicit priority. >>> >>> I'm still unclear what you're asking for. Is it some short >>> editorial text to discuss client considerations for choosing >>> the value of u or i parameters? >> >> [BB2] Here I was reacting to your statement that "Only a >> client knows how it wants to use resources for which it has >> limited knowledge. " >> Last night I noticed that [MEEHAN] starts out by saying the >> opposite: >> "Historically the browser has been in control of deciding >> how and when web content is loaded. Today we are introducing >> a radical change to that model ... that puts control into the >> hands of the site owner directly. " >> >> A control point cannot exercise its control well if it is >> lacking necessary information. That's what a protocol is for. >> Here, I was trying to analyse what information was lacking >> where and when. But, I think I had better just step back from >> trying to improve the protocol at this stage. >> >> >> [LP2] The challenges are innate to HTTP. There are some means to >> give the client better data, some exist in HTTP and others exist >> in HTML or other things that are outside the remit of the IETF. >> This is why we acknowledge servers might look beyond just the >> priority signal, to other client headers or anything else that >> might fill in some gaps. The hardest thing is that client and >> server are flying close to the latency edge and that >> reprioritization can be too slow to make it worthwhile after the >> client learns what the server knows. >> >> I can imagine some new Extensible Priority parameters that might >> help to improve the situation. For example, a client could >> present multiple sets of parameters and instruct the server to >> select on based some variable condition (if content-length < N >> use set 1, else use set 2). However, this is a new speculative >> capability that so far no one has mentioned or screamed for. >> >> >> [BB2] Nonetheless, I just noticed a new editorial point, in >> §9 on client scheduling. The text made me think §9 is about >> what priority values a client puts in its requests. But >> perhaps it meant: >> CURRENT: >> >> A client MAY use priority values to make local processing or >> scheduling choices about the requests it initiates. >> >> Was this intended to say?: >> >> A client MAY use priority values to make local processing or >> scheduling choices about the responses to the requests it initiated. >> >> >> This text is quite old. I think (personally) it probably actually >> is meant to say the values MAY apply to both requests and >> responses. Worth further thought so I created >> https://github.com/httpwg/http-extensions/issues/1868 >> <https://github.com/httpwg/http-extensions/issues/1868> >> > > [BB3] I've responded there. > > > [LP3] Cool > > >> >> >>> >>>> If we use an HTML document as an example, the subresources >>>> have a dependency chain that may or may not change while >>>> they get loaded. It’s more likely that a client will >>>> request something with a particular priority because of its >>>> type and usage in a given HTML document, rather than its >>>> size (even if it knew that size). It’s going to be rare >>>> that a client doesn't have an opinion - if the client >>>> doesn’t know, the defaults are sufficient to let it >>>> reprioritize the request higher or lower if it finds out >>>> that need once the response is back. >>>> >>>> But really this all comes down to making all the actors >>>> aware of the challenges and stating that priority signals >>>> are just hints in the decision making. If a client finds >>>> that the server is making scheduling choices when using >>>> defaults, then it is empowered to provide better signals. >>>> >>>> The general problem is not solvable so I do not believe >>>> there is anything more we can add to the document. >>> >>> [BB] Apart from the fundamental problem of A&B having >>> info in the wrong place (see above)... I believe the >>> missing piece is an ability for the client to be able to >>> distinguish between "I'm certain" and "I really don't >>> know". As you explained earlier, "all requests are >>> treated as if they have an associated priority signal", >>> so the client has no way to express "I really don't know". >>> >>> I've said that multiple times now, and it seems to be >>> falling on stony ground, so I'll stop. Maybe I'm wrong, >>> but I've said as strongly as I can that I think this >>> will be a problem. >>> >>> >>> I think we can agree to disagree on this one. If it does >>> really turn into a problem, we can convert that into an >>> opportunity to define a new parameter for this scheme to >>> address it. For example, imagine a new "confidence" >>> parameter between 0 and 100 that expresses the confidence of >>> the priority signal it was sent with., >> >> [BB2] Yes. Again, I'll step back from trying to improve the >> protocol at this stage. >> >>> >>>> >>>> §10. Server Scheduling >>>> >>>> T#10a) Server push priority sounds like waffle >>>> >>>> [BB-follow-up]: When I said "which I believe is >>>> often the case" I didn't intend to mean the >>>> majority of cases. I meant "not an insignificant >>>> number". >>>> I'm sure the client can have a crack at how to set >>>> the priorities in common cases. Which can then be >>>> modified by the server if necessary. >>>> >>>> The point I was trying to highlight was that the >>>> client has no way to tell the server how to >>>> distinguish between "I'm certain about these >>>> priorities" and "I'm not really sure, but the >>>> protocol requires me to look as if I'm sure, even >>>> if I just leave everything as default priority." >>>> I think I explained it better under T#9a. >>>> >>>> >>>> The discussion of priority for server push seems to say >>>> "This might not work". >>>> If this conclusion is based on operational experience >>>> it ought to say so. And >>>> if it's not, it ought to say that it's just conjecture. >>>> >>>> >>>> The topic of server push is not helped by the fact that >>>> it’s deployment story, outside this I-D, is one of >>>> disappointment. But we’re stuck with that feature in HTTP/2 >>>> and HTTP/3 and a server that chooses to use it while >>>> implementing this scheme has to make some choices. There's >>>> no case where push will fail but there are cases that could >>>> cause it to perform badly. The text in paragraphs 10 and 11 >>>> provide considerations that a server that does implement >>>> server push will have to make (because things are _always_ >>>> contending for resource). That said, I don’t think we need >>>> operational experience to conclude that if you push things >>>> incorrectly, you could really hurt what the client is >>>> trying to achieve. >>> >>> [BB] This doesn't answer my question. The text is >>> essentially blustering. Please just say that there is >>> little operational experience to go on, if there isn't. >>> Rather than trying to say something that sounds wise,... >>> and failing. >>> >>> >>> [LP] I disagree. Server push is the initiation of a response >>> based on a request that a client never made. The server has >>> to pick something. And we know that what it picks will >>> interplay with non-pushed resources. We spell out the >>> problem that if you don't consider these things, problems >>> could happen. We don't need operational experience to reason >>> that guessing wrong is suboptimal when picking scheduling >>> using this scheme. >> >> [BB2] OK, I should have said that the draft needs to say that >> any /solution/ would be conjecture due to lack of operational >> experience (you're right, the problem can be predicted >> without ops experience). >> >> If there were operational experience, the draft might be able >> to give some advice on what is the least harmful thing to do. >> But, as it stands, these paras end in mid-air, with no >> explanation for why no advice is given. >> >> >> [LP2] Thanks for the clarification. That's a slightly different >> sort of problem. In these cases the answer is implementation >> driven and we know that sever implementations do different >> things. I think the document is consistent in its treatment. >> Stating something like "these considerations mean we have no >> specific advice" doesn't seem much help. > > [BB3] I asked to say sthg like "without more implementation > experience no useful advice can be given." but this isn't > important enough for me to keep arguing about. > > > [LP3] In the server push section we already say " There is no general > guidance on the best way to apply these.". Even with implementation > experience, I doubt useful advice can be given. Therefore, making a > statement that implementation experience would produce useful advice > is highly speculative and next to useless IMO. I think its best for us > to move on from this point. [BB4] Thanks Bob > > >> >> >>>> >>>> >>>> §12. Retransmission Scheduling >>>> >>>> T#12a) Sounds like more waffle >>>> Similarly, if retransmission scheduling and/or probe >>>> scheduling has limited >>>> operational experience or limited usefulness, it would >>>> be better to say so, >>>> rather than trying to sound authoritative without >>>> really saying anything. >>>> >>>> >>>> Again, this is something a server has to do anyway and we >>>> want to present the considerations at play. Our editorial >>>> change makes it sound less authoritative by nixing the >>>> sentence containing “...its effectiveness can be further >>>> enhanced…”. >>>> >>>> >>>> §13. Fairness >>>> >>>> T#13a) Please define fair. Seriously. >>>> >>>> A prerequisite question is, "What parameters does a >>>> server scheduler >>>> manipulate?" The text implies the server can only >>>> control the order in which it >>>> starts a response to each request, and whether >>>> responses start while other >>>> responses are in progress or wait for their completion. >>>> If so, I'm not sure >>>> what fairness could mean. >>>> >>>> Presumably a server can also determine the relative >>>> rate at which it sends >>>> different streams. And it could stall a stream to allow >>>> another absolute >>>> priority. In this context, fairness might mean >>>> instantaneously equal rates. But >>>> that's not fair if the objects are of different sizes. >>>> >>>> So we genuinely do need to see a definition of what >>>> fairness means here. >>>> >>>> >>>> Good point, we addressed this in issue 1819 - >>>> https://github.com/httpwg/http-extensions/issues/1819 >>>> <https://github.com/httpwg/http-extensions/issues/1819> >>> >>> [BB] I've read the issue, but I think it reveals >>> unstated assumptions about what fair means. To >>> understand what I mean by "equal rates are not fair if >>> the objects are of different sizes", please see the >>> description around Fig 1 in this discussion paper: >>> https://bobbriscoe.net/projects/latency/per-flow_tr.pdf#page.3 >>> <https://bobbriscoe.net/projects/latency/per-flow_tr.pdf#page.3> >>> >>> (The context is transport layer, not app-layer, but the >>> arguments are the same. In the next response, I try to >>> pull together app-layer and transport layer fairness). >>> >>> >>>> >>>> T#13b) Why not make scheduling decisions across >>>> different clients? >>>> >>>> As a general guideline, a server SHOULD NOT use >>>> priority information >>>> for making scheduling decisions across multiple >>>> connections, unless >>>> it knows that those connections originate from the >>>> same client. >>>> >>>> Why does the IETF have anything to say about this? It's >>>> surely an operator >>>> policy decision. >>>> >>>> >>>> We disagree a bit with this but we discused some more on >>>> issue 1820 - >>>> https://github.com/httpwg/http-extensions/issues/1820 >>>> <https://github.com/httpwg/http-extensions/issues/1820> >>> >>> [BB] I've read 1820, and the new text in draft-11. >>> Typically, HTTP implementations depend on the underlying transport to >>> maintain fairness between connections competing for bandwidth. >>> >>> Interesting. But you (the apps area) don't appear to >>> know your own strength... >>> >>> When the endpoints set the non-incremental parameter on >>> streams A,B,C,D,E , it is equivalent to giving B-E zero >>> rate until A completes, then C-E zero rate until B >>> completes, etc. >>> >>> So, I think most transport area people would say the >>> opposite of the above; the transport layer handles >>> relative rates of connections, but only in the absence >>> of more conscious bandwidth scheduling driven from the >>> app layer (or intervention by the network operator, >>> which is the other stakeholders that might apply >>> bandwidth policy, but it has very weak visibility and >>> knowledge of the information it is handling). >>> >>> The transport area offers no meaningful guidance on >>> app-layer fairness. For instance, the app-layer decides: >>> a) which streams to hold back from being allowed to send >>> (as just described above); >>> b) which streams are collected together within one >>> 5-tuple flow; >>> c) how much data to send into each socket. >>> So the app-layer determines the units of fairness that >>> the transport layer has to work with. The transport >>> area's only contribution has been rate-equality between >>> flow IDs competing in a common bottleneck. So I suggest >>> you consider transport layer 'fairness' as just an >>> arbitrary default policy that is merely the easiest way >>> to prevent starvation. But always remember that the >>> app-layer can override the transport layer and impose >>> starvation (e.g. with the non-incremental parameter, as >>> described above). >>> >>> In the transport area, there have been some recent >>> advance in understanding, allowing that rate equality >>> between flow IDs only becomes more necessary as >>> congestion rises. The corollary being that, when >>> congestion is low, more inequality is OK. IOW >>> rate-equality is most useful as a famine response. >>> >>> When >>> HTTP requests are forwarded through intermediaries, progress made by >>> each connection originating from end clients can become different >>> over time, depending on how intermediaries coalesce or split requests >>> into backend connections. This unfairness can expand if priority >>> signals are used.Section 13.1 <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority-11#section-13.1> andSection 13.2 <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority-11#section-13.2> discuss mitigations >>> against this expansion of unfairness. >>> >>> >>> There seems to be an (incorrect) implication that >>> different progress between end-clients is unfair. >>> However, given end-clients have different available >>> bandwidths in the general case, it will be 'fair' that >>> their rates are unequal. For instance: >>> * Client A has a 100Mb/s downstream access bottleneck, >>> but it is currently shared by 4 other applications >>> * Client B is using a 120Mb/s downstream bottleneck >>> exclusively for itself. >>> It would be wrong here for an http intermediary to >>> allocate equal bandwidth between two http applications >>> run by these two clients, which would merely serve to >>> take bandwidth from the other 4 applications, and waste >>> some of B's capacity. >>> >>> This is the sense in which it's best to allow the >>> transport layer to share out the bandwidth (which >>> includes some ideas that never took off, like bandwidth >>> brokers between applications). But the app layer is >>> still controlling the bigger levers of bandwidth allocation. >>> >>> >>> [LP] Thanks. There's some good knowledge here that I'll >>> defer to Kazuho to respond on better than I. I'm open to >>> nailing down definitions better if it will help. >>> >>> FWIW we give recommendations for servers to avoid starving >>> on situations like 5 non-incremental requests. Really, >>> servers want to keep transport connection bandwidth capacity >>> as full as possible. The available capacity is a product of >>> various factors - HTTP/2 flow control can add a whole >>> dimension of implementer fun. If we imagine a scenario where >>> the client makes 5 non-incremental requests where the >>> contents are written to 5 different disk drives; if response >>> A gets flow-control blocked by the client because the disk >>> is full, then the server can switch to B if it likes. >> >> [BB2] OK, I'll watch for the responses deferred to Kazuho on >> two points. >> I'll probably be going off line until the New Year now. >> >> >> Me too, enjoy! >> >> Cheers >> Lucas >> >> [1] https://interop.seemann.io/ <https://interop.seemann.io/> >> [2] https://cache-tests.fyi/ <https://cache-tests.fyi/> >> [3] https://github.com/summerwind/h2spec >> <https://github.com/summerwind/h2spec> >> [4] >> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.1.3.p.2 >> <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.1.3.p.2> >> > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ <http://bobbriscoe.net/> > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
- [Tsv-art] Tsvart last call review of draft-ietf-h… Bob Briscoe via Datatracker
- Re: [Tsv-art] Tsvart last call review of draft-ie… Bob Briscoe
- Re: [Tsv-art] Tsvart last call review of draft-ie… Lucas Pardue
- Re: [Tsv-art] Tsvart last call review of draft-ie… Lucas Pardue
- Re: [Tsv-art] Tsvart last call review of draft-ie… Bob Briscoe
- Re: [Tsv-art] Tsvart last call review of draft-ie… Lucas Pardue
- Re: [Tsv-art] Tsvart last call review of draft-ie… Bob Briscoe
- Re: [Tsv-art] Tsvart last call review of draft-ie… Lucas Pardue
- Re: [Tsv-art] Tsvart last call review of draft-ie… Bob Briscoe
- Re: [Tsv-art] Tsvart last call review of draft-ie… Lucas Pardue
- Re: [Tsv-art] Tsvart last call review of draft-ie… Bob Briscoe
- Re: [Tsv-art] Tsvart last call review of draft-ie… Kazuho Oku