Specify keep-alive and idle timeouts

[MOZGIII]

The spec does not mention anything abut the keep-alive and idle timeouts.

The protocol itself permits setting protocol-level keep-alive, as well as the idle timeout. The application code should be able to, at the very least, request those parameters from the browser to learn what to expect, and ideally to request the parameters it would like during the transport setup.

I suggest allowing setting the optional keep-alive and idle timeouts, and throwing TypeError if they are not valid/acceptable. A reasonable fallback for the apps them would be to try negotiating the parameters by instantiating the WebTransport in a sequence, of attempts and catching the errors; with the ultimate fallback of not passing any keep-alive and idle timeout options.

---

Additions to WebTransport options:

• keepaliveIntervalSeconds (optional) - an duration of time, specified in seconds; if set, the browser will send a keel-alive packets to the server with this intervals. Can be used to keep idle but otherwise healthy connection from expiring.
• idleTimeoutSeconds (optional) - a duration of time, specified in seconds; specifies the browser side of idle timeout negotiation, the effective idle timeout if the minimum of durations suggested by the browser and the server; idle timeout specifies how long the WebTransport session will remain connected after the last activity it had; once the session becomes inactive, timeout errors will be emitted for all currently waiting operations.

Additions to the WebTransport API:

• keepaliveIntervalSeconds (property, undefined | number, readonly) - the effective keep-alive interval for this session.
• idleTimeoutSeconds (property, number, readonly) - the effective idle timeout for this session; 0 means no timeout.

[jan-ivar]

WebTransport now uses the same HTTP/3 back-end as fetch. AFAIK fetch doesn't expose keep-alive and idle timeouts. Why should WebTransport?

Having concrete examples of use cases would be useful.

[MOZGIII]

fetch has different API, and it is intended for request/response operations that are typically short lived, while WebTransport can be long-lived and it starts to matter. Note that it could also benefit from the ability to tweak keepalive / idle parameters - although it is not so much of an issue there.

WebTransport could be used for a mobile game for instance, where the application would want to know and/or tweak the timings of the keepalive to allow the session to keep idle connections longer as users can move around. Think about users going into a tunnel to catch a pokemon and then going out to resume where they left off.

Another example is an ngrok-like tunneling app, where the users and service providers might want to agree to let the session live for hours when idle, as this can be important for when the user moves locations (i.e. you go from the office to home while maintaining the same session).