Re: QUIC idle timeouts and path idle timeouts

[Lucas Pardue <[e-mail]>]

Hey Dan,

On Wed, Jul 24, 2024, at 14:30, Dan Wing wrote:
> On Jul 24, 2024, at 11:24 AM, Lucas Pardue <[e-mail]> wrote:
>> 
>> Hi folks,
>> 
>> Wearing no hats.
>> 
>> There's been some chatter this week during IETF about selecting QUIC idle timeouts in the face of Internet paths that might have shorter timeouts, such as NAT.
>> 
>> This isn't necessarily a new topic, there's past work that's been done on measurements and attempts to capture that as in IETF documents. For example, Lars highlighted a study of home gateway characteristics from 2010 [1]. Then there's RFC 4787 [2], and our very own RFC 9308 [3]
>> 
>> There's likely other work that's happened in the meantime that has provided further insights.
>> 
>> All the discussion got me wondering whether there might be room for a QUIC extension that could hint at the path timeout to the peer. For instance, as a server operator, I might have a wide view of network characteristics that a client doesn't. Sending keepalive pings from the server is possible but it might not be in the client's interest to force it to ACK them, especially if there are power saving considerations that would be hard for the server to know. Instead, a hint to the peer would allow it to decide what to do. That could allow us to maintain a large QUIC idle timeouts as befitting of the application use case, but adapt to the needs of the path for improved connection reliability. 
>> 
>> Such an extension could hint for each and every path, and therefore a benefit to multipath, which has some addition path idle timeout considerations [4].
>> 
>> Thoughts?
> The client has to send a message to keep firewalls or NATs from timing out UDP connections; it can't be kept alive solely from the server.
> 
> If, after a NAT (or firewall) timeout closes the mapping (or pinhole), a new QUIC message is initiated by the client, a NAT (or firewall) timeout is not harmful to a QUIC connection because of the connection-id, as you know. It might cost a round trip if the server decides it needs to be validated.  However, if in that same situation the new QUIC message is initiated by the server, it will be dropped because the NAT mapping or firewall pinhole is gone.  I believe that is the problematic use-case?  If so, would it be useful for the server to tell the client "I will want to send an unsolicited application message to you"?  The client could use that to keep the firewall pinhole or NAT mapping alive.
The application bearing messages are STREAM and DATAGRAM frames, which are both ack-eliciting. I don't think this problem is impactful enough to motivate developing a new non-ack eliciting application dara frame. But perhaps a transport level mechanism could work, and be applicable to everything by default.

Cheers
Lucas
> 
> -d
>