Keep alive advice

[martinthomson]

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.

[mirjak]

While this all sounds good, isn't this basically provided by having a connection close signal from the application? Meaning, if the application didn't indicate to close the connection, quic keeps the connection open and by default sends pings every 15-30ms?

I guess you can have another interface where the application can change the keep alive interval (and potentially set it infinity to never send any).

Further, if no keep-alives are used, there are actually also two options in the case where the application did not close the connection and tries to send something but this fails (because path state is gone). Eiter quic can tell the application that it failed, or it could seamlessly try to reconnect...

[ianswett]

The use case the draft had in mind with it's current text was when there was an open request(ie: a hanging get).

There's typically no need to do a keepalive unless one expects to get a response, since the concern is a NAT binding expiring. And keepalives aren't free, so it's best to avoid them when we can.

I agree with you Martin, this should be driven from an application signal. Your 3 proposals sound fine to me.

[janaiyengar]

Yes, the text was intended for "dynamic streams", which in Google-QUIC means any stream that's not the crypto or the HTTP stream. I'm leaning towards (3), with some additional advice about time, but there's a caveat: the application does not know when the last packet was sent by QUIC. Meaning that the app isn't in the best position to judge how long the network has been idle.

[martinthomson]

That caveat is a good addition. To be clear, I was proposing to do ALL three things that I listed.