change more transport config after connection is established

[FlorianUekermann]

We would like to change some transport config details after the connection is already established. In particular we are interested in:

• max_idle_timeout
• keepalive_interval
• pad_to_mtu

The reason for the first two is that different stages of the connection lifecycle make different settings reasonable (small values make for a responsive experience, but can have a large impact on power consumption on mobile). This can be worked around in most cases on the application level, but only if the user controls the application protocol.

The reason for the latter is that it is mostly a privacy option, which protects to an extent against fingerprinting. This has a significant performance cost in some network environments (Wifi), even if the total transmission size doesn't actually change much. Therefore it would be good to be able to configure this on an already running connection, without adding more entropy for fingerprinting to the handshake (e.g. configuration hints via SNI).

I wanted to ask what your thoughts are on these before working on PRs.

[djc]

Seems reasonable to me. I wonder if any of these result in state changes that propagate outward from just the configuration value in ways that we'd have to correct for?

[Ralith]

The idle timeout can't be reliably changed on an existing connection because it's part of the transport parameters sent to the peer, the peer is responsible for respecting the value it receives, and no mechanism exists to notify the peer of a change. I don't see any immediate problems with the others, though of course adjusting the keep-alive interval to a value that exceeds the negotiated idle timeout isn't very useful.

[FlorianUekermann]

Oh. Interesting. I thought keep-alive / idle-timeout mechanism was just based on emitting something that makes the remote send an ack and tracking time since the last datagram was received. Seems like I need to do some reading.