Re: WGLC for draft-ietf-httpbis-connect-tcp

[Ben Schwartz <[e-mail]>]

I don't think it makes sense to add a dependency on the Capsule Protocol here, given the significant additional complexity and (at present) zero added value.  If the Capsule Protocol becomes relevant, future implementations can negotiate it via the Capsule-Protocol header field.

As an example of the complexity, note that all uses of the Capsule Protocol to date are "atomic": each capsule is expected to be buffered and processed as a whole.  In this thread we've heard proposals to introduce new capsule types that the recipient must process in "streaming" fashion.  This mix of atomic and streaming capsules is a new wrinkle in the Capsule Protocol.

Regarding multiple IPs: adding this capability later is difficult because we do not have a well-defined extension mechanism (unless we are willing to derive capabilities from the template's variable names).  The extensibility problem also applies when considering retrofitting this capability to Connect-UDP (in addition to some other problems specific to UDP).

--Ben
________________________________
From: Lucas Pardue <[e-mail]>
Sent: Wednesday, March 6, 2024 6:32 PM
To: David Schinazi <[e-mail]>
Cc: Tommy Pauly <[e-mail]>; Ben Schwartz <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: Re: WGLC for draft-ietf-httpbis-connect-tcp

On Wed, 6 Mar 2024, 23: 15 David Schinazi, <dschinazi. ietf@ gmail. com> wrote: First, to respond to Tommy's chair comment about WGLC: I absolutely agree this needs more review. Additionally, I think we should wait for implementation
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd


On Wed, 6 Mar 2024, 23:15 David Schinazi, <[e-mail]<mailto:[e-mail]>> wrote:
First, to respond to Tommy's chair comment about WGLC: I absolutely agree this needs more review. Additionally, I think we should wait for implementation experience before sending it to the IESG.

Now, to respond to Tommy's technical points as individual:

When we originally developed the capsule protocol, I was worried about the consequences of taking over the data stream. Luckily, there's a straightforward solution: we define a DATA capsule - the semantics of all DATA capsules is that they are concatenated to create the DATA stream. That would allow us to have message content ("body") with methods that rely on the capsule protocol.

I hadn't really thought about it in the context of connect-tcp, but I like that idea. We could say that connect-tcp always uses the capsule protocol, and then uses DATA capsules to encode the CONNECT/TCP bytestream. It's a little bit more code on the receiver, and pretty much none on the sender (just send a DATA capsule with length=2^61).

I think what you're saying is DATA capsules could be used to provide agility in whether implementations interleave Capsules or not.

A common concern I hear is that any level of framing risks losing an ability to "splice" the post-CONNECT data stream onto a consumer. That reduces performance compared to classic CONNECT. I think using a large DATA capsule adds trivial overhead before deciding if a splice is OK or not - implementations already have to read HEADERS before switching to that mode.

The nice property of allowing other capsules before switching into a large DATA, is that it could allow for custom capsule types to exchange metadata that doesn't fit well in CONNECT-associated headers. For instance, some binary blob that is larger than typical header size limits on the Internet.

Cheers
Lucas