Re: Proposal: a new WRAP UP capsule

[David Schinazi <[e-mail]>]

On Tue, Jul 9, 2024 at 1:26 PM Lucas Pardue <[e-mail]> wrote:

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

In my scenario, we control the clients so we can guarantee that they
support WRAP_UP. But having the client send it is cheap so I'm ok with
adding that signal if we find a real server operator that has a need for it.

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

Oh that's interesting. Yeah I can see value in a DO_STUFF capsule too.
David

Cheers
> Lucas
>