Idle timeout, keep alives, and what do we do if the web app doesn't use the transport?

[pthatcherg]

The idea of using pooled connections (https://github.com/w3c/webrtc-quic/issues/105) made me think more about idle timeouts for them, which made me think about idle timeouts in general for all QuicTransports and RTCQuicTransports.

Here's the question: what do we do if the two endpoints of the QUIC connections haven't sent any traffic for the length of QUIC's idle timeout? I see two options:

A. Keep the connection alive until QuicTransport.stop() is called. But then we have to choose a way to keep it alive, such as using PING frames. And now we're headed down the path of defining a protocol on top of QUIC, which I'd like to avoid.

B. Close the QuicTransport. But this implies we need to provide a way to the client keep the connection alive if it wants.

Here are a few options for that:

B1. Let the client (or server) keep things alive by sending streams or datagrams. That's easy for servers, but clients (especially those with pooled connections) It could, of course, simply send things constantly (perhaps writing to a stream or writing a datagram) wouldn't know how often it needs to do that, and so it may waste bytes on the wire when it doesn't need to.

B2. Let the client set the idle timeout. It can pick a large value if it wants and also know how often to send its own traffic (see B1; still doesn't work great for pooled connections).

B3. Let the client know when a connection is about to timeout. This solves the issue for pooled connections, but it may also leak information about how often other users of the pooled connection are using it, which could potentially be an issue. Plus, it would be tricky to define a signal that fires just before the timeout, but not too much before and not too little before.

B4. Give the client an attribute like "bool QuicTransport.sendPingsToPreventIdleTimeout". If true, when we'd normally timeout, send a PING frame instead. This is like A, but explicit. It's like B1 and B2, but uses PINGs. It's like B3 but doesn't leak anything. And it works for pooled connections.

[pthatcherg]

Editor's meeting note: we should make the idle timeout transport parameter for p2p cases be very large (effectively infinite). And if we connect to a mobile app, it's up to you to sort it out. So this isn't an issue for the p2p case, and really just for the client/server.

[pthatcherg]

Editor's meeting note: we're going with B4. Bernard will make the PR. It will apply only to client/server, not p2p.

[aboba]

Editor's meeting note: Add a writeable attribute to the QuicTransport (will only apply to C/S).