[connect-tcp] Discuss use of the Capsule Protocol

[bemasc]

No description provided.

[bemasc]

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

[kazuho]

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.

[bemasc]

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.

[LPardue]

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

[kazuho]

@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.

[DavidSchinazi]

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.

[bemasc]

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.

[DavidSchinazi]

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.

[DavidSchinazi]

You can't infer what end-to-end extensions a server supports from one request, because different requests can be routed to different backends even if they are sent over the same client-intermediary connection. For this to work I think we need to mandate server support.

[bemasc]

That's fine in this case. The client uses the capsule protocol until it encounters a request where that is rejected. Then, for the rest of the "session" it sticks to baseline. Once your server fleet is finished upgrading to capsule support, clients will use it reliably (if they support it).

If you want, we could soften the notion of a "session" to indicate that clients can retry after a reasonable amount of time.

[MikeBishop]

"MUST disable for the rest of the session" is a bit strong. "MUST retry without the Capsule Protocol and MAY disable for all future requests" is all that's actually needed. Let implementations decide how aggressive they want to be about backing off in a heterogeneous environment.

[bemasc]

@MikeBishop OK, I've made that change.

[DavidSchinazi]

The current text still uses the word "session" without defining what that means. But at this point we're in the weeds, I'm ok with merging this and then figuring out the details in separate smaller issues/PRs