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.

Sign up for GitHub

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

Jump to bottom

[connect-tcp] Discuss use of the Capsule Protocol #2847

Merged
merged 8 commits into from
Aug 2, 2024
Merged

[connect-tcp] Discuss use of the Capsule Protocol #2847

Changes from 2 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
34ae1d6
[connect-tcp] Discuss use of the Capsule Protocol
bemasc Jul 26, 2024
71407cb
Editorial simplification
bemasc Jul 26, 2024
b4e6675
Avoid vexing parse
bemasc Jul 26, 2024
29f03cc
Reduce repetition
bemasc Jul 26, 2024
863fc1e
Define fallback flow to enable safe optimistic use
bemasc Jul 31, 2024
aeab5c1
Apply suggestions from David Schinazi
bemasc Aug 1, 2024
f1c9783
Add temporary registry values and adjust wording
bemasc Aug 1, 2024
d75aaae
Get more specific about client retry/fallback
bemasc Aug 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 13 additions & 3 deletions draft-ietf-httpbis-connect-tcp.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -145,11 +145,13 @@ Authentication to a templated TCP proxy normally uses ordinary HTTP authenticati

Clients SHOULD assume that all proxy resources generated by a single template share a protection space (i.e., a realm) ({{?RFC9110, Section 11.5}}). For many authentication schemes, this will allow the client to avoid waiting for a "401 (Unauthorized)" response before each new connection through the proxy.

## Relationship to the Capsule Protocol
### Use of the Capsule Protocol

Unlike the datagram-oriented templated HTTP proxying specifications {{CONNECT-UDP}}{{CONNECT-IP}}, this specification does not make use of the Capsule Protocol {{?RFC9297}}. A future specification could define a procedure for performing TCP proxying using the Capsule Protocol, but no such procedure is defined here.
In this specification, use of the Capsule Protocol {{?RFC9297}} is OPTIONAL. Clients MAY request use of the Capsule Protocol by including a "Capsule-Protocol: ?1" header field in the request, and servers MAY confirm its use by echoing this header field in the response.

When implementing this specification, clients and servers MUST NOT send a "Capsule-Protocol: ?1" header field.
When using the Capsule Protocol, TCP data is sent using a new Capsule Type named DATA ({{data-capsule}}). The DATA type is only applicable when the use of the Capsule Protocol is optional. It conveys a payload that should be processed in the same way as ordinary stream contents when the Capsule Protocol is not in use.
kazuho marked this conversation as resolved.
Show resolved Hide resolved

A client that sends this header field MUST NOT send any data on the stream until it receives a response, because it does not know whether the server will treat the data as Capsule Protocol or TCP contents.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This latency cost is unfortunate, and could be avoided by making Capsule Protocol mandatory to implement for servers. However, that would increase the implementation complexity for a minimal compliant server, and should not be done lightly.

@DavidSchinazi @mnot

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, current design allows you to do various optimisations such calling splice (2) to avoid making copies to / from userspace, or pass the socket to some other process (with TLS being offloaded to the kernel). If we are to mandate the use of Caspules, those optimisations become impossible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A middle ground would be to keep this text, and later define a way for servers to commit to supporting the Capsule Protocol. Note that the HTTPS record would likely not work for this commitment, because it must be fully authenticated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I share the performance concerns. Something Ilthat came up when I talked about this with @DavidSchinazi is the possibility of having a $humongous data frame that extends to the end of the stream, so that endpoints can opt out of needing capsule framing if they don't believe they need to send any other capsules.

I havent thought exactly about how that works across intermediaries for the different use cases we discussed during the IETF 120 neeting

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@LPardue

Something Ilthat came up when I talked about this with @DavidSchinazi is the possibility of having a $humongous data frame that extends to the end of the stream, so that endpoints can opt out of needing capsule framing if they don't believe they need to send any other capsules.

I'm not sure if that solves the performance concerns; the approach provides a escape hatch for senders, but it does not provide a way for the receivers to stay out from the business of decoding Capsules.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Decoding capsules is pretty trivial. We're already decoding HTTP/3 frames and QUIC frames by the time we're reading this data stream.

Yeah, current design allows you to do various optimisations such calling splice (2) to avoid making copies to / from userspace, or pass the socket to some other process (with TLS being offloaded to the kernel). If we are to mandate the use of Caspules, those optimisations become impossible.

That's not true when you're using HTTP/2 or HTTP/3, and there is no reason to optimize HTTP/1.1 at this point.

I really do care about allowing the client to send data with the request. And we can't do that without requiring capsule support on the server: we just need to say that any server implementing this specification MUST NOT read the data stream if it doesn't agree with the value of the Capsule-Protocol header sent by the client.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really do care about allowing the client to send data with the request.

OK, I've reworked this text to make that safe while keeping capsule support optional, based on your suggestion.

there is no reason to optimize HTTP/1.1 at this point.

I have heard that HTTP/3->HTTP/1.1 conversion at a gateway is a common pattern, so the performance of HTTP/1.1 may be significant even if it is not heavily used over the open internet.


# Additional Connection Setup Behaviors

Expand Down Expand Up @@ -230,6 +232,14 @@ IF APPROVED, IANA is requested to add the following entry to the "MASQUE URI Suf
| Path Segment | Description | Reference |
| tcp | TCP Proxying | (This document) |

## New Capsule Type {#data-capsule}
bemasc marked this conversation as resolved.
Show resolved Hide resolved

IF APPROVED, IANA is requested to add the following entry to the "HTTP Capsule Types" registry:

| ----- | ------------ | --------- | ----------------- | ------- |
| Value | Capsule Type | Status | Change Controller | Contact |
| (TBD) | DATA | permanent | IETF | HTTPBIS |

--- back

# Acknowledgments
Expand Down
Loading