[quicwg/base-drafts] Keep alive advice (#729)

[Martin Thomson <[e-mail]>]

Providing the right sort of keep-alive mechanisms is hard.  TCP failed at this.

QUIC is currently following in august footsteps.  The PING frame description has this text:

> The PING frame SHOULD be used to keep a connection alive when a stream is open. 

This is bad advice: HTTP will have a stream open always.

What this wants to say is that a connection should be kept alive based on some application-driven signal that the connection is needed.  In HTTP, this might be reduced to if you have open requests or unfulfilled server push promises.  Other protocols have different keep-alive semantics.

I propose that we do this:

1. Change the description of the PING frame to say that if the application wishes to keep the connection live, then a PING frame can be sent periodically (along multiple path if maintaining multiple paths is desired).  This ensures that middleboxes don't drop state while the connection is still actively in use.  We might also say that experience with middleboxes suggests that a number between 15 and 30 seconds ensures that the greatest number of middleboxes will retain state (we can cite REQ-5 of RFC 4787 here and note that the internet sometimes doesn't pay attention to RFCs).

2. Add to that description a requirement on application protocols.  If the protocol requires keep-alive at any time, it should specify the conditions under which a keep-alive is required *and the peer that is expected to maintain that keep-alive*.  Experience with SIP has shown that the server often knows more about the keep-alive timers, so negotiating the time can be more effective than having the client drive things.

3. Change the HTTP draft to include specific advice on when to maintain the connection and say that the client should drive this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/729