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

Agreed that we don’t necessarily need to have the details of capsules here, but it might be good to mention it or explain how it would work. If someone does add the Capsule-Protocol header to a connect-tcp request, should we say that servers should reject it (until we have a well-defined behavior for capsules)? Although at that point, I’d wonder if it’s actually a relatively small section to add to define what the capsules mean…

Tommy

> On Mar 7, 2024, at 9:18 AM, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
> 
> Hey,
> 
> On Thu, 7 Mar 2024, 17:00 Ben Schwartz, <bemasc@meta.com <mailto:bemasc@meta.com>> 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 <lucaspardue.24.7@gmail.com <mailto:lucaspardue.24.7@gmail.com>>
>> Sent: Wednesday, March 6, 2024 6:32 PM
>> To: David Schinazi <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>>
>> Cc: Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>>; Ben Schwartz <bemasc@meta.com <mailto:bemasc@meta.com>>; HTTP Working Group <ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>>
>> Subject: Re: WGLC for draft-ietf-httpbis-connect-tcp
>>  
>> 
>> 
>> On Wed, 6 Mar 2024, 23:15 David Schinazi, <dschinazi.ietf@gmail.com <mailto: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 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