Re: Proposal: a new WRAP UP capsule

Hey

On Tue, Jul 9, 2024, at 20:37, Ben Schwartz wrote:
> I agree, an "I support WRAP UP" signal is not very useful for the *server*.  It's useful for the server *operator*, to try to answer questions like:
> 
> * Do enough of our clients support WRAP UP that we should invest some effort implementing it?
> * Is our implementation of WRAP UP working correctly?
> * How long a grace period do we need to offer to reach 99% graceful termination among supporting clients?

I think these are good points.

Personally, I would measure these things empirically. Supporting graceful close in general is already a common industry practice. Extending that to individual requests is a natural evolution.  But that's just me, others might see it differently and require an explicit market intelligence signal.

Sending a capsule is trivial. Gracefully closing is probably where more of the effort is. But then every server I know has a bunch of limits and timeouts already. So the additional work might be easy to justify.

This actually makes me think of a different problem I've observed that is sort of  opposite of David's proposal. Servers detecting idle or slow loris streams and shutting them down. So spitballing, would there be any benefit in capsule that could prompt the client to do something more with a stream or risk it being garbage collected before WRAP UP termination is started. 

For example, a MASQUE server might have timeouts on the egress side based on packet exchanges. Keeping that socket alive for an idle end-to-end connection has a cost to the proxy. The proxy is probably not aware of the tunneled connection properties, such as the e2e QUIC idle timeout. A proxy closing the socket prematurely has a cost to client and server. To avoid it can require endpoints to have to send e2e signals (such as a keepalive packet) when they otherwise might not need to. A client to proxy signal to register continued interest in an idle flow could, in theory, improve on this situation.

Cheers
Lucas