Limit pushes using MAX_PUSH_ID by martinthomson · Pull Request #711 · quicwg/base-drafts

martinthomson · 2017-08-08T08:39:15Z

This repurposes SETTINGS_ENABLE_PUSH as the initial limit.

A client can use this to limit the number of outstanding pushes. I've included
advice on increasing the limit, not as the pushes are first used, but as the
pushes are completed (or cancelled).

There wasn't a rule for handling a truncated push stream header, so I added
that as well. The HTTP_DUPLICATE_PUSH error was reclaimed for signaling all
three types of error with a push stream header: truncation, duplicate Push ID,
and exceeding MAX_PUSH_ID.

Closes #709.

RyanTheOptimist · 2017-08-08T20:34:41Z

+The MAX_PUSH_ID frame (type=0xA) is used by clients to control the number of
+server pushes that the server can initiate.  This sets the maximum value for a
+Push ID that the server can use in a PUSH_PROMISE frame.  Consequently, this
+also limits the number of push streams that the server can initiate.


I'm not sure I'm following this completely. Clearly MAX_PUSH_ID limits the number of promises that the server can make. But isn't the number of actual push streams limited by the MAX_STREAM_ID?

(This makes me wonder if "Promise ID" might be a better name than "Push ID" but I may well just be confused.)

You can't deliver a push that hasn't been promised, so the actual limit is whichever is smaller.

Good point. (Though I think it common practice we expect the promise limit to be higher than the stream limit so we would not expect this to be the lower of the two.) Perhaps the text could say:

Consequently, this also limits the number of push streams that the server can initiate in conjunction with MAX_STREAM_ID.

(or some such)

MikeBishop

Generally good; minor nits other than the frame ID.

MikeBishop · 2017-08-08T21:48:56Z

+of type HTTP_MALFORMED_PUSH.
+
+A server SHOULD use Push IDs sequentially, starting at 0.  A client uses the
+MAX_PUSH_ID frame ({{frame-max-push-id}}) and SETTINGS_MAX_PUSH_ID


Nit: I'd mention these in the order they're used; the setting to provide an initial value and the frame to increment it later.

MikeBishop · 2017-08-08T21:51:27Z

+MAX_PUSH_ID frame ({{frame-max-push-id}}) or the SETTINGS_MAX_PUSH_ID setting
+({{settings-parameters}}).  A client that receives a PUSH_PROMISE that contains
+a larger Push ID than is allowed MUST be treated as a connection error of type
+HTTP_MALFORMED_PUSH_PROMISE.


"is allowed" makes it sound like an absolute limit; might be worth rewording slightly.

MikeBishop · 2017-08-08T21:56:16Z


+# MAX_PUSH_ID {#frame-max-push-id}
+
+The MAX_PUSH_ID frame (type=0xA) is used by clients to control the number of


Note that you're now conflicting with the frame type for the ALTSVC frame in the HTTP/2 registry. ORIGIN is using 0xC, which suggests someone has 0xB but I can't think of who off the top of my head right now. Might want to jump out to at least 0xD to be safe, or (ab)use 0x8 instead.

MikeBishop · 2017-08-08T21:58:29Z

+for a Push ID that the server can use (see {{frame-push-promise}}).  A
+MAX_PUSH_ID frame cannot reduce the maximum Push ID; receipt of a MAX_PUSH_ID
+that contains a smaller value than previously received MUST be treated as a
+connection error of type HTTP_MALFORMED_MAX_PUSH_ID.


General comment: Because these are on the control stream, which means guaranteed in-order delivery, we could use the HTTP/2 model of sending an increment rather than an absolute number. I'm not sold that the few bytes saved are worth it, though.

I think that we can make a bigger saving here by not sending the frame as often, noting that MAX_STREAM_ID covers the resource exhaustion issue.

I don't think the savings are worth it, since this shouldn't be sent that often really as it is.

On resource exhaustion, I think both MAX_STREAM_ID and MAX_PUSH_ID both cover that issue, just at different levels. QUIC decides MAX_STREAM_ID based on its resource constraints for streams, and the HTTP "layer" decides MAX_PUSH_ID based on its constraints for handling pushed resources. I think these are independent.

MikeBishop · 2017-08-08T22:13:01Z

-HTTP_SETTINGS_ON_WRONG_STREAM (0x0F):
-: A SETTINGS frame was received on a request control stream.
+HTTP_WRONG_STREAM (0x0F):
+: A frame was received on a different stream to where it is permitted.


"different... to" is British; "different... than" is American. "Different... from" is neutral. Maybe we should use that, or just sidestep the issue with "on a stream where it is not permitted."

I learn something every day. I say that in its most Lovecraftian meaning, of course.

MikeBishop · 2017-08-09T16:10:46Z

+A server SHOULD use Push IDs sequentially, starting at 0.  A client uses the
+SETTINGS_MAX_PUSH_ID ({{settings-parameters}}) setting and the MAX_PUSH_ID frame
+({{frame-max-push-id}}) to limit the number of pushes that a server can promise
+initiate.  A client MUST treat receipt of a push stream with a Push ID that is


"promise initiate" needs to have only one word or a conjunction.

janaiyengar

Thanks, Martin! Looks great. A few comments.

janaiyengar · 2017-08-09T21:26:16Z

+for a Push ID that the server can use (see {{frame-push-promise}}).  A
+MAX_PUSH_ID frame cannot reduce the maximum Push ID; receipt of a MAX_PUSH_ID
+that contains a smaller value than previously received MUST be treated as a
+connection error of type HTTP_MALFORMED_MAX_PUSH_ID.


I don't think the savings are worth it, since this shouldn't be sent that often really as it is.

On resource exhaustion, I think both MAX_STREAM_ID and MAX_PUSH_ID both cover that issue, just at different levels. QUIC decides MAX_STREAM_ID based on its resource constraints for streams, and the HTTP "layer" decides MAX_PUSH_ID based on its constraints for handling pushed resources. I think these are independent.

janaiyengar · 2017-08-09T21:32:53Z

-HTTP_SETTINGS_ON_WRONG_STREAM (0x0F):
-: A SETTINGS frame was received on a request control stream.
+HTTP_WRONG_STREAM (0x0F):
+: A frame was received on a different stream from where it is permitted.


from -> than ? I mostly don't care because it might be about local idioms, but it took me a moment to parse :-)
Offline, Ryan suggested "A frame was received on stream where it is not permitted", which SGTM as well (though it is semantically slightly different).

I took Ryan's text, but I moved that to #712. This PR will appear to be include the change, but that's just because I rebased on top of #712 on the assumption that it will be merged.

janaiyengar · 2017-08-09T21:47:41Z

+    maximum Push ID that a server can use.  This setting only has meaning when
+    set by a client; a server MUST NOT provide a value for this setting.  A
+    client MUST treat receipt of this setting from a server as a connection
+    error of type HTTP_MALFORMED_SETTINGS.


Can this be 0? I assume so, since there's no other way to disable PUSH now. Can you state this explicitly here (that a client can disable push by setting this value to 0)?

janaiyengar · 2017-08-09T21:49:36Z

+server pushes that the server can initiate.  This sets the maximum value for a
+Push ID that the server can use in a PUSH_PROMISE frame.  Consequently, this
+also limits the number of push streams that the server can initiate in addition
+to the limit set by the QUIC MAX_STREAM_ID frame.


It seems silly but possible to send this with 0. Can you add a sentence that says this MUST be > 0?

janaiyengar · 2017-08-09T21:59:44Z

+The MAX_PUSH_ID frame carries a 32-bit Push ID that identifies the maximum value
+for a Push ID that the server can use (see {{frame-push-promise}}).  A
+MAX_PUSH_ID frame cannot reduce the maximum Push ID; receipt of a MAX_PUSH_ID
+that contains a smaller value than previously received MUST be treated as a


I would explicitly state that this previous value may have been received via MAX_PUSH_ID or SETTINGS_MAX_PUSH_ID. Perhaps "a smaller value than that received via a previous MAX_PUSH_ID or SETTINGS_MAX_PUSH_ID ..." ?

Sending a frame with a value less than you provided in transport settings is a clear error, actually, since you know the transport settings necessarily came before the frame.

HTTP_MALFORMED_DATA description mentioned HEADERS and it wasn't in the IANA table. HTTP_WRONG_STREAM was defined as HTTP_SETTINGS_ON_WRONG_STREAM.

This repurposes SETTINGS_ENABLE_PUSH as the initial limit. A client can use this to limit the number of outstanding pushes. I've included advice on increasing the limit, not as the pushes are first used, but as the pushes are completed (or cancelled). There wasn't a rule for handling a truncated push stream header, so I added that as well. The HTTP_DUPLICATE_PUSH error was reclaimed for signaling all three types of error with a push stream header: truncation, duplicate Push ID, and exceeding MAX_PUSH_ID.

janaiyengar · 2017-08-10T00:48:13Z

Heh -- thanks for rephrasing, it's one of those trivial yet annoying things.

…

On Wed, Aug 9, 2017 at 5:46 PM, Martin Thomson ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In draft-ietf-quic-http.md <#711 (comment)>: > @@ -857,14 +910,17 @@ HTTP_INTERRUPTED_HEADERS (0x0E): : A HEADERS frame without the End Header Block flag was followed by a frame other than HEADERS. -HTTP_SETTINGS_ON_WRONG_STREAM (0x0F): -: A SETTINGS frame was received on a request control stream. +HTTP_WRONG_STREAM (0x0F): +: A frame was received on a different stream from where it is permitted. I took Ryan's text, but I moved that to #712 <#712>. This PR will appear to be include the change, but that's just because I rebased on top of #712 <#712> on the assumption that it will be merged. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#711 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKjg1CBuuPYrMA7q8eURZwd82JARTWNcks5sWlLTgaJpZM4OwaxD> .

martinthomson added -http design An issue that affects the design of the protocol; resolution requires consensus. labels Aug 8, 2017

martinthomson requested a review from MikeBishop August 8, 2017 08:39

RyanTheOptimist reviewed Aug 8, 2017

View reviewed changes

MikeBishop reviewed Aug 8, 2017

View reviewed changes

MikeBishop reviewed Aug 9, 2017

View reviewed changes

janaiyengar reviewed Aug 9, 2017

View reviewed changes

martinthomson force-pushed the push-id-seq branch from b6bcd43 to 95ff370 Compare August 10, 2017 00:42

martinthomson added 7 commits August 10, 2017 10:44

Fix error code definitions

a7ac6f1

HTTP_MALFORMED_DATA description mentioned HEADERS and it wasn't in the IANA table. HTTP_WRONG_STREAM was defined as HTTP_SETTINGS_ON_WRONG_STREAM.

So much effort spent on something so trivial

0926843

Fix error codes, prohibit reduction

3b7aa26

Review comments

f633213

Remove push setting in favor of MAX_PUSH_ID

9b96a44

Remove redundant word

b38ae53

martinthomson force-pushed the push-id-seq branch from 95ff370 to b38ae53 Compare August 10, 2017 00:47

martinthomson mentioned this pull request Aug 10, 2017

Retain use of SETTINGS_ENABLE_PUSH #718

Closed

Merge branch 'master' into push-id-seq

494a48f

MikeBishop merged commit 90e2eea into master Aug 16, 2017

MikeBishop deleted the push-id-seq branch August 16, 2017 17:13

twdkeule mentioned this pull request Aug 23, 2017

Add support for HTTP/2 SETTINGS frame quic-go/quic-go#775

Closed


		# MAX_PUSH_ID {#frame-max-push-id}

		The MAX_PUSH_ID frame (type=0xA) is used by clients to control the number of

Uh oh!

Conversation

martinthomson commented Aug 8, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MikeBishop left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

janaiyengar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

janaiyengar commented Aug 10, 2017 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

martinthomson commented Aug 8, 2017 •

edited

Loading