Skip to content
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

Field:Flow ID cardinality #9

Closed
martinthomson opened this issue Dec 14, 2020 · 3 comments · Fixed by #18
Closed

Field:Flow ID cardinality #9

martinthomson opened this issue Dec 14, 2020 · 3 comments · Fixed by #18

Comments

@martinthomson
Copy link
Contributor

It's not really clear whether there are any expectations in relation to cardinality of flow identifiers and the field. Can two fields refer to the same flow ID? Can the same request reference multiple flow IDs?

@martinthomson martinthomson changed the title Field:Flow ID ratio Field:Flow ID cardinality Dec 14, 2020
@DavidSchinazi
Copy link
Collaborator

I think the h3 datagram draft should allow both:

  • two requests can reuse the same flow ID if the definition of that HTTP features allows it (this feature is used by the QUIC extension to CONNECT-UDP)
  • one request can reference two flow IDs - I think this is already stated though:

For example, an HTTP method that wishes to use two datagram flow identifiers for the lifetime of its request stream could encode the second flow identifier as a parameter

@martinthomson
Copy link
Contributor Author

I'm sure that people operating intermediaries might have something to say here. A gateway that routes flows might be unwilling to replicate datagram flows that are bound to requests that go to different origin servers.

I agree that one request to many flows is worthwhile, but mention in examples doesn't really count as a specification.

@DavidSchinazi
Copy link
Collaborator

Fair enough, I'll add text to make this clearer. And I'll add a note to the intermediaries section about how the intermediary needs to ensure that if a second request arrives that shares a flow ID with a previous one, the intermediary MUST either send the new request to the same backend or reject it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants