PRIORITY_UPDATE can be used for initial priority, split H3 frames into two types #1167

LPardue · 2020-04-30T13:45:24Z

This attempts to address #1096 and #1079. It might help towards overcoming the headers vs frames debate.

I made the call to restrict the PRIORITY_UPDATE frame to only be sent by clients.

It replaces ASCII art with new QUIC-style frame definitions.

ianswett

It seems like there may be some opportunities for de-duplicating some text, but I don't have a specific suggestion.

draft-ietf-httpbis-priority.md

LPardue · 2020-05-07T17:43:56Z

Wouldn't it be easier to just define h2's stream zero as the control stream for h2 (at top of document)?

In my head that's what I call it. However, @kazuho has been quite particular with correcting me back use stream zero terminology in the past.

@kazuho WDYT about Roy's suggestion to define stream zero as control in this document?

draft-ietf-httpbis-priority.md

kazuho · 2020-05-14T01:08:39Z

draft-ietf-httpbis-priority.md

 ~~~
-{: #fig-h2-reprioritization-frame title="HTTP/2 PRIORITY_UPDATE Frame Payload"}
+{: #fig-h2-reprioritization-frame title="HTTP/2 PRIORITY_UPDATE Frame"}


Seeing the definition of the frame headers for H2 was surprising to me, though I understand that it reflects the change to the HTTP/3 draft. Maybe I should ask if the change in HTTP/3 is a good thing.

As a personal opinion I prefer to see the frame in whole because it avoids having to cross reference to the frame headers, which are defined in some other document.

But I can drop them if people want. I see that as an editorial change so perhaps we can avoid blocking this and fix up later if needs be.

I agree that this is an editorial issue, and that we need to ask the WG to resolve (because it is about the convention covering all H2 extensions, not just this one).

FWIW, ALTSVC is the only extension to have reached RFC status previously. It does not include the frame header; only the payload.

You forgot ORIGIN frame https://tools.ietf.org/html/rfc8336#section-2.1 which also specifies the frame payload.

Now that H2 and H3 have different frame format definitions, I think extensions applicable to both will hit this problem. I'd like to figure what people think is the most acceptable way to present things.

One option would be to write documents that update RFC 7838 and RFC 8336 to use the new format and define the H3 frame at the same time...

True, I try to block that one out.

They have different frame format definitions, sure; the question is whether the payload needs to vary between H2/H3. I think the real things you need to specify are:

What stream it's on (part of the header in H2, intrinsic property in H3)

Control stream vs. stream zero language plays into this

Flags if used in H2; since H3 doesn't have flags, this might lead to a payload difference

Payload

The simplest path for dual-version extensions is not to use flags and only define the payload.

Taking the feedback received here and elsewhere, I'm reverted the diagram back to our traditional format.

kazuho · 2020-05-14T01:14:39Z

@LPardue

WDYT about Roy's suggestion to define stream zero as control in this document?

I'd be fine with that, assuming that we'd have the definition somewhere (as @royfielding suggests).

LPardue · 2020-05-15T12:03:19Z

This PR changes the HTTP/3 frame format in a breaking way, which is unfortunate because we don't have strong versioning in the extension. It's feasible that interop between endpoints that expect the frame could suffer because they parse them differently.

One idea is to link the priorities draft version to the HTTP/3 draft version. For example, agree that priorities-01 would be used with h3-28. However, the drafts will progress at different rates and we might get stuck.

@kazuho made a suggestion that would avoid this problem. We we pick a large frame type ID that we change for each version of the priorities draft. The final draft that is ready for RFC can then switch back the "nice" lower values. I'll make a commit that actions this proposal in order to get review feedback.

LPardue · 2020-05-15T12:35:19Z

127f149 adds "big numbers" for the H3 frame types but leaves the H2 frame as 0xF, mainly because H2's space is only 8 bit and I don't want to pollute it. Maybe others also want an experimental value there but IMO we can progress without it.

ianswett · 2020-05-15T13:26:49Z

FWIW, I'm ok with changing the frame type value, but in our code it's just as easy(or easier) to switch by draft version.

LPardue · 2020-05-15T13:33:08Z

FWIW, I'm ok with changing the frame type value, but in our code it's just as easy(or easier) to switch by draft version.

My concern is that we'll see an uncoordinated staggered rollout of new HTTP/3 endpoints, and that clients talk something different than the server expects, causing the frame parsing to fail and generating a connection error.

ianswett · 2020-05-15T18:00:31Z

Our servers will likely support draft 25, 27 and 28 at once.

Is the concern that servers will support multiple drafts at once, and clients will typically only support a single version, but server connections won't be aware of what version they're speaking?

I suspect this is a case of different implementations having very different ways of supporting multiple versions of QUIC at once?

LPardue · 2020-05-15T18:09:49Z

I hope implementation know what draft they are speaking! I'm more worried about needed to rev the priority draft version multiple times; if we couple to draft 28 we get stuck unless there is a draft 29. I anticipate priorities could iterate more quickly than the specification and more quickly than people might be able to deploy different versions.

Using a unique big number for frame type would even allow implementations to retrofit it to draft 27, which might be more feasible to implement and test in the short term.

ianswett · 2020-05-15T18:14:03Z

Thanks for clarifying @LPardue, that makes sense. I was a bit confused about how one might not know what version they're speaking.

kazuho

Thank you for the changes. Looks good modulo one point below.

draft-ietf-httpbis-priority.md

martinthomson · 2020-05-22T03:13:28Z

draft-ietf-httpbis-priority.md

+Unlike the Priority header field, the PRIORITY_UPDATE frame is a hop-by-hop
+signal. Clients that do not want to expose an end-to-end signal MAY omit the
+header field but send the PRIORITY_UPDATE frame at an early moment assuming that
+it will reach the server as early as the request message it applies to. The


The important "when" here is "before prioritization information is not useful to the server". That might be later than when the server receives the request.

draft-ietf-httpbis-priority.md

martinthomson · 2020-05-22T03:16:46Z

draft-ietf-httpbis-priority.md

+references has been created. The Stream ID MUST be within the client-initiated
+bidirectional stream limit. If a server receives a PRIORITY_UPDATE for a Stream


This needs to be qualified; if the frame contains a Push ID, then this doesn't apply.

draft-ietf-httpbis-priority.md

thanks! Co-authored-by: ianswett <[email protected]>

Strawman proposal. In HTTP/3 we have a huge space of possible frame types, so lets use them during draft development. The values in this commit were picked by generating a set of GREASE values, selecting one and adding 1 and 2 to it. The HTTP/2 frame type remains as 0xF because it is only 8-bits, meaning there is less room to play and greater chance of polluting a small range. However, I also expect less churn in H2, partly because I anticipate that implementers of the draft will focus on HTTP/3. Since we intend to reserve the values 0xF and 0x10 in the final RFC, I've left the IANA consideration unchanged. I have reserved the selected experimental values in the temporary IANA registry at https://github.com/quicwg/base-drafts/wiki/Temporary-IANA-Registry.

Co-authored-by: Martin Thomson <[email protected]>

LPardue · 2020-05-26T23:55:54Z

We also discussed this PR during the May 2020 virtual interim and the conversation segued into a discussion about reprioritization which is related but ultimately is tracked separately in #1021.

As editor, I believe this PR adds changes that better describe the protocol with the design it had when adopted by the WG. And therefore it can be merged independent of the WG finding consensus on reprioritization.

I've received a lot of feedback on this PR (thanks) and believe I've addressed all but one comment. I aim to resolve that one soon and then plan to merge this PR unless I hear some pushback.

guoye-zhang · 2020-07-15T04:35:35Z

draft-ietf-httpbis-priority.md

-The HTTP/3 PRIORITY_UPDATE frame (type=0xF) carries the identifier of the
-element that is being reprioritized, and the updated priority in ASCII text,
-using the same representation as that of the Priority header field value.
+The HTTP/3 PRIORITY_UPDATE frame (type=0x1CCB8BBF1F0700 or 0x1CCB8BBF1F0701) is


Is it 0x1CCB8BBF1F0700/0x1CCB8BBF1F0701 or 0x10/0x11?

In HTTP/3, the value should be the long 0x1CCB8BBF1F0700/0x1CCB8BBF1F0701, I'll fix this up.

LPardue · 2020-09-07T22:36:13Z

This issue got tied up with the discussion about reprioritization. Now that the chairs believe there is rough consensus on the matter, I'm giving fair warning that I'm aiming to land this change in the next day or two. I'll remind folks that this has had pretty substantial review already and I'm not looking for relitigation.

I've just pushed two commits: 1) revert the H2 frame diagram format, we can tackle this later if we care. 2) fix an inconsistency in frame type values report by @guoye-zhang.

There is an open question about a servers ability to understand a safe limit of buffering, which might be subject to implementation API. I'd like to spin that off into it's issue so we can make progress here.

LPardue · 2020-09-08T13:13:00Z

FYI I had some feedback that the frame type values were a bit cumbersome so I've shortened them to 0xF0700 and 0xF0701. See b007e93

kazuho

@LPardue Thank you for all the work. LGTM, just editorial suggestions.

draft-ietf-httpbis-priority.md

Co-authored-by: Kazuho Oku <[email protected]>

MikeBishop

All of these are nits except for the "within the stream limit" conversation on the HTTP/2 piece. Feel free to split that to a separate issue if needed.

draft-ietf-httpbis-priority.md

Co-authored-by: Mike Bishop <[email protected]>

…o two types (httpwg#1167) * Fill out TODOs in PRIORITY_UPDATE, split H3 frames into two types * Allow PRIORITY_UPDATE as initial signal * Reserved the selected experimental frame type values in the temporary IANA registry at https://github.com/quicwg/base-drafts/wiki/Temporary-IANA-Registry. * Incorporate a bunch of suggestions from Roy and others Co-authored-by: ianswett <[email protected]> Co-authored-by: Martin Thomson <[email protected]> Co-authored-by: Kazuho Oku <[email protected]> Co-authored-by: Mike Bishop <[email protected]>

LPardue requested a review from kazuho April 30, 2020 13:45

LPardue mentioned this pull request Apr 30, 2020

Initial priority frame #1168

Closed

LPardue added the priorities label May 1, 2020

LPardue changed the title ~~Fill out TODOs in PRIORITY_UPDATE, split H3 frames into two types~~ PRIORITY_UPDATE can be used for initial priority, split H3 frames into two types May 4, 2020

ianswett approved these changes May 5, 2020

View reviewed changes

draft-ietf-httpbis-priority.md Outdated Show resolved Hide resolved

draft-ietf-httpbis-priority.md Outdated Show resolved Hide resolved

royfielding reviewed May 5, 2020

View reviewed changes

draft-ietf-httpbis-priority.md Outdated Show resolved Hide resolved

royfielding approved these changes May 7, 2020

View reviewed changes

kazuho reviewed May 14, 2020

View reviewed changes

kazuho reviewed May 15, 2020

View reviewed changes

draft-ietf-httpbis-priority.md Outdated Show resolved Hide resolved

bencebeky approved these changes May 21, 2020

View reviewed changes

martinthomson reviewed May 22, 2020

View reviewed changes

LPardue and others added 10 commits May 22, 2020 15:01

Fill out TODOs in PRIORITY_UPDATE, split H3 frames into two types

f8640ef

Allow PRIORITY_UPDATE as initial signal

56415dc

Apply Ian's suggestions

187a8e2

thanks! Co-authored-by: ianswett <[email protected]>

Incorporate a tweaked version of Roy's suggestion

2bc1227

Kazuho's suggested test for frame signalling

000e4c8

Define control stream term and use it

782bda7

fix double 0x

84a4424

fix missing 0

e7cf2b6

h2 frame should always be 0xF

437b0a2

LPardue and others added 4 commits May 22, 2020 15:01

Kazuho's suggestion

23e66e5

stream ID value in frame drawing

ee65018

Co-authored-by: Martin Thomson <[email protected]>

s/MUST/SHOULD when stream IDs are beyond limits

9a2f9e4

Co-authored-by: Martin Thomson <[email protected]>

frame type starts at 0x10, and goes up to 0x11!

41432cb

LPardue force-pushed the priority-update-frames branch from 11f28fd to 41432cb Compare May 22, 2020 14:04

Stronger qualification of frame types and rules

e1a5f17

avoid discussing that clients might just use frames

ca71a49

guoye-zhang reviewed Jul 15, 2020

View reviewed changes

LPardue added 2 commits September 7, 2020 23:03

Define H2 frame in it's customary format

021e7ca

consistently use new H3 frame type value

ae7ef87

LPardue force-pushed the priority-update-frames branch from 8b064e5 to ae7ef87 Compare September 7, 2020 22:18

LPardue added 2 commits September 7, 2020 23:41

remove erroneous term

357b2ae

shorten PRIORITY_UPDATE type value

b007e93

kazuho approved these changes Sep 8, 2020

View reviewed changes

draft-ietf-httpbis-priority.md Outdated Show resolved Hide resolved

draft-ietf-httpbis-priority.md Outdated Show resolved Hide resolved

draft-ietf-httpbis-priority.md Show resolved Hide resolved

draft-ietf-httpbis-priority.md Outdated Show resolved Hide resolved

LPardue and others added 2 commits September 8, 2020 15:36

Kazuho's field appendum

f441d5f

Co-authored-by: Kazuho Oku <[email protected]>

change PRIORITY_UPDATES to PRIORITY_UPDATE frames

c45f532

LPardue mentioned this pull request Sep 8, 2020

Buffering PRIORITY_UPDATES and early responses #1260

Closed

MikeBishop reviewed Sep 8, 2020

View reviewed changes

LPardue and others added 3 commits September 8, 2020 21:37

Apply Mike's suggestions

805e5c5

Co-authored-by: Mike Bishop <[email protected]>

More Mike's suggestions

0c35a0e

Co-authored-by: Mike Bishop <[email protected]>

disambiguate HTTP/2 frame payload by using Prioritized Stream ID

01414f5

MikeBishop mentioned this pull request Sep 9, 2020

"Within the stream limit" in HTTP/2? #1261

Closed

has been

fd1c710

LPardue merged commit 8eb70f8 into master Sep 9, 2020

LPardue deleted the priority-update-frames branch September 9, 2020 21:13

LPardue mentioned this pull request Oct 7, 2021

Merge reprioritization section with frame section #1721

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PRIORITY_UPDATE can be used for initial priority, split H3 frames into two types #1167

PRIORITY_UPDATE can be used for initial priority, split H3 frames into two types #1167

LPardue commented Apr 30, 2020 •

edited

Loading

ianswett left a comment

LPardue commented May 7, 2020

kazuho May 14, 2020

LPardue May 14, 2020

kazuho May 14, 2020

MikeBishop May 14, 2020

LPardue May 14, 2020

LPardue May 14, 2020

MikeBishop May 15, 2020

LPardue Sep 7, 2020

kazuho commented May 14, 2020

LPardue commented May 15, 2020

LPardue commented May 15, 2020

ianswett commented May 15, 2020

LPardue commented May 15, 2020

ianswett commented May 15, 2020

LPardue commented May 15, 2020

ianswett commented May 15, 2020

kazuho left a comment

martinthomson May 22, 2020

martinthomson May 22, 2020

LPardue commented May 26, 2020

guoye-zhang Jul 15, 2020

LPardue Sep 7, 2020

LPardue commented Sep 7, 2020 •

edited

Loading

LPardue commented Sep 8, 2020

kazuho left a comment

MikeBishop left a comment

		references has been created. The Stream ID MUST be within the client-initiated
		bidirectional stream limit. If a server receives a PRIORITY_UPDATE for a Stream

PRIORITY_UPDATE can be used for initial priority, split H3 frames into two types #1167

PRIORITY_UPDATE can be used for initial priority, split H3 frames into two types #1167

Conversation

LPardue commented Apr 30, 2020 • edited Loading

ianswett left a comment

Choose a reason for hiding this comment

LPardue commented May 7, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kazuho commented May 14, 2020

LPardue commented May 15, 2020

LPardue commented May 15, 2020

ianswett commented May 15, 2020

LPardue commented May 15, 2020

ianswett commented May 15, 2020

LPardue commented May 15, 2020

ianswett commented May 15, 2020

kazuho left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LPardue commented May 26, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LPardue commented Sep 7, 2020 • edited Loading

LPardue commented Sep 8, 2020

kazuho left a comment

Choose a reason for hiding this comment

MikeBishop left a comment

Choose a reason for hiding this comment

LPardue commented Apr 30, 2020 •

edited

Loading

LPardue commented Sep 7, 2020 •

edited

Loading