New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Priority grouping node ambiguity #441

Closed
mcmanus opened this Issue Apr 18, 2017 · 11 comments

Comments

6 participants
@mcmanus
Contributor

mcmanus commented Apr 18, 2017

in h2 'phantom' (unopened) streams can be used for grouping nodes for priority purposes. This is simultaneously very useful and very concerning from a resource commitment purpose. I'm aware of some servers looking to limit their use through implicit resource allocations, and I'm aware of some clients looking to use them more agressively (i.e. a grouping node per tab).

Perhaps we should at least make these explicitly negotiated so they can be cleaned up, limited, etc..?

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Apr 18, 2017

Member

This is a really useful feature in h2, it's a shame that we currently don't have any ability to support it in hq.

Member

martinthomson commented Apr 18, 2017

This is a really useful feature in h2, it's a shame that we currently don't have any ability to support it in hq.

@mcmanus

This comment has been minimized.

Show comment
Hide comment
@mcmanus

mcmanus Apr 18, 2017

Contributor

I think when doing 7540 the http wg decided some kind of grouping was essential for combining 2 uncoordinated groups into one connection. Proxies combining n connections into 1 is one use case, browsers combining n tabs into one connection is pretty much the same problem.

The implicit unopened stream was probably a mistake, but the 'requirement' still makes sense as something quic would need

Contributor

mcmanus commented Apr 18, 2017

I think when doing 7540 the http wg decided some kind of grouping was essential for combining 2 uncoordinated groups into one connection. Proxies combining n connections into 1 is one use case, browsers combining n tabs into one connection is pretty much the same problem.

The implicit unopened stream was probably a mistake, but the 'requirement' still makes sense as something quic would need

@MikeBishop

This comment has been minimized.

Show comment
Hide comment
@MikeBishop

MikeBishop Apr 18, 2017

Contributor

In Chicago, I had a side conversation with someone advocating that we rip out the priority scheme as a whole and enable different schemes to be used on an extension basis. (Which reminds me, I had promised to send this person the link to one of the alternatives that was proposed in late H2.... Doing that now.) I think a priority scheme that explicitly provided buckets of streams rather than using phantoms would be reasonable. However, that feels like it wanders into the realm of work that HTTPbis should be doing, rather than the QUIC WG; when there's not a specific "this doesn't work in QUIC because...", I'm loathe to make fundamental protocol changes without at least a commission from the owning WG.

However, I don't know that I'd say HTTP/QUIC doesn't support the phantoms -- can't you just close the streams you want to use as placeholders without making a request? Though perhaps we should have text that explicitly states that this is "normal" behavior, just for clarity's sake.

Contributor

MikeBishop commented Apr 18, 2017

In Chicago, I had a side conversation with someone advocating that we rip out the priority scheme as a whole and enable different schemes to be used on an extension basis. (Which reminds me, I had promised to send this person the link to one of the alternatives that was proposed in late H2.... Doing that now.) I think a priority scheme that explicitly provided buckets of streams rather than using phantoms would be reasonable. However, that feels like it wanders into the realm of work that HTTPbis should be doing, rather than the QUIC WG; when there's not a specific "this doesn't work in QUIC because...", I'm loathe to make fundamental protocol changes without at least a commission from the owning WG.

However, I don't know that I'd say HTTP/QUIC doesn't support the phantoms -- can't you just close the streams you want to use as placeholders without making a request? Though perhaps we should have text that explicitly states that this is "normal" behavior, just for clarity's sake.

@mnot mnot added this to Streams in QUIC Apr 28, 2017

@mnot mnot changed the title from fix priority grouping node ambiguity to Priority grouping node ambiguity Jun 21, 2017

@martinthomson martinthomson added -http and removed -transport labels Jan 16, 2018

@MikeBishop

This comment has been minimized.

Show comment
Hide comment
@MikeBishop

MikeBishop Feb 6, 2018

Contributor

I floated a proposal as an HTTP/2 extension, in the form of https://tools.ietf.org/html/draft-bishop-httpbis-priority-placeholder (expired draft). That didn't get much traction on the HTTP/2 side, though there was at least one comment that we should just do this in HTTP/QUIC directly.

Are we interested in adopting that approach in HTTP/QUIC separately from HTTP/2? If not, something else or just close this and live with it?

Contributor

MikeBishop commented Feb 6, 2018

I floated a proposal as an HTTP/2 extension, in the form of https://tools.ietf.org/html/draft-bishop-httpbis-priority-placeholder (expired draft). That didn't get much traction on the HTTP/2 side, though there was at least one comment that we should just do this in HTTP/QUIC directly.

Are we interested in adopting that approach in HTTP/QUIC separately from HTTP/2? If not, something else or just close this and live with it?

@ianswett

This comment has been minimized.

Show comment
Hide comment
@ianswett

ianswett Feb 6, 2018

Contributor

I think this is worth discussion. Given this wouldn't need to be an extension for QUIC, if we did this, I'd like to see strict rules on when one can depend upon a stream. ie: streams can only depend upon placeholders or leaf node streams.

Or we should do something entirely different.

Contributor

ianswett commented Feb 6, 2018

I think this is worth discussion. Given this wouldn't need to be an extension for QUIC, if we did this, I'd like to see strict rules on when one can depend upon a stream. ie: streams can only depend upon placeholders or leaf node streams.

Or we should do something entirely different.

@MikeBishop

This comment has been minimized.

Show comment
Hide comment
@MikeBishop

MikeBishop Feb 6, 2018

Contributor

I think I'd prefer strict rules about pruning the tree. I don't so much want to constrain the tree's structure as make sure both sides have a consistent view of it, which is one of the biggest drawbacks of the strategy in h2.

Contributor

MikeBishop commented Feb 6, 2018

I think I'd prefer strict rules about pruning the tree. I don't so much want to constrain the tree's structure as make sure both sides have a consistent view of it, which is one of the biggest drawbacks of the strategy in h2.

@ianswett

This comment has been minimized.

Show comment
Hide comment
@ianswett

ianswett Feb 6, 2018

Contributor

I strongly support not taking the existing H2 priority scheme with no modifications.

Contributor

ianswett commented Feb 6, 2018

I strongly support not taking the existing H2 priority scheme with no modifications.

@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Feb 7, 2018

Contributor

My preference goes to making minimal changes to the H2 prioritization tree.

If there is a benefit in switching to an approach other than the one we use in H2, it is likely that the HTTPx over TCP would would benefit from the switch as well. So why not do that in HTTPWG?

Going back to the topic of what the minimal change could be, I think the only thing that we need to do is find a code point for grouping node.

Fortunately, we have that space: the number space for client->server unidirectional streams. By definition, H2 priority is a scheme for controlling server's emission. Therefore, there is a guarantee that client -> server unidirectional streams will never be covered by prioritization.

I admit that this sounds like a hack. But proposing it anyways since IMO it demonstrates what a minimal change could look like.

Contributor

kazuho commented Feb 7, 2018

My preference goes to making minimal changes to the H2 prioritization tree.

If there is a benefit in switching to an approach other than the one we use in H2, it is likely that the HTTPx over TCP would would benefit from the switch as well. So why not do that in HTTPWG?

Going back to the topic of what the minimal change could be, I think the only thing that we need to do is find a code point for grouping node.

Fortunately, we have that space: the number space for client->server unidirectional streams. By definition, H2 priority is a scheme for controlling server's emission. Therefore, there is a guarantee that client -> server unidirectional streams will never be covered by prioritization.

I admit that this sounds like a hack. But proposing it anyways since IMO it demonstrates what a minimal change could look like.

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Feb 7, 2018

Member

There is also the possibility of defining explicit request identifiers rather than use stream IDs for identifying requests. That has some benefits.

Member

martinthomson commented Feb 7, 2018

There is also the possibility of defining explicit request identifiers rather than use stream IDs for identifying requests. That has some benefits.

@martinthomson

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Mar 13, 2018

Member

We need the HTTP WG to discuss this. If they can, they can produce a new priority signaling scheme. If they do, QUIC will use that. If they don't, QUIC will have to make the h2 scheme work.

Since it seems unlikely that HTTP will produce a fast answer for us, we will probably need to do the latter.

Member

martinthomson commented Mar 13, 2018

We need the HTTP WG to discuss this. If they can, they can produce a new priority signaling scheme. If they do, QUIC will use that. If they don't, QUIC will have to make the h2 scheme work.

Since it seems unlikely that HTTP will produce a fast answer for us, we will probably need to do the latter.

@MikeBishop

This comment has been minimized.

Show comment
Hide comment
@MikeBishop

MikeBishop Mar 15, 2018

Contributor

Discussed further at editors' meeting; we're sufficiently pessimistic that HTTP will adopt anything new in time, so we will proceed with a proposal to keep parity. The current candidate is to expand Push ID into a Request ID system, and then achieve parity by permitting the client to skip IDs.

Contributor

MikeBishop commented Mar 15, 2018

Discussed further at editors' meeting; we're sufficiently pessimistic that HTTP will adopt anything new in time, so we will proceed with a proposal to keep parity. The current candidate is to expand Push ID into a Request ID system, and then achieve parity by permitting the client to skip IDs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment