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

[Lucas Pardue <[e-mail]>]

On Wed, 6 Mar 2024, 23:15 David Schinazi, <[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