Hey Dan, On Wed, Jul 24, 2024, at 14:30, Dan Wing wrote: > On Jul 24, 2024, at 11:24 AM, Lucas Pardue <[email protected]> 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 >
