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

[Lucas Pardue <[e-mail]>]

Hey,

On Thu, 7 Mar 2024, 17:00 Ben Schwartz, <[e-mail]> wrote:

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

FWIW the capsule protocol spec highlights this and normatively recommends
streaming https://datatracker.ietf.org/doc/html/rfc9297#section-3.2-12.
Whether implementations do or don't is an implementation matter.
Intermediaries that don't processes datagrams would not benefit from
buffering them. That might have influenced capsule implementations, a
survey would be useful.

H2 and H3 implementations already have to deal with streaming of frames. I
dont think streaming capsules would add much complexity for them.

I do agree a capsule based connect-tcp could be added as a separate
extension mode. I don't have much strong opinion on whether we do it that
way, or by default.

Cheers
Lucas


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