Re: QUIC idle timeouts and path idle timeouts

[Christian Huitema <[e-mail]>]

As Ian writes, the problem is on the server, not at the client. If the 
client wakes up with something to send after a long silence, it can 
decide to just resume the connection. But the server can't. If the 
client connection is dropped, the server is stuck.

The current solution is to use keep-alives. But this is painful for both 
clients and servers. For clients, that means waking up each time any of 
the 17 messenger applications on the phone sends a keep alive, wakes up 
the radio, and drains the battery. For servers, that means getting 
messages from every client every 15 seconds, even if they only have 
messages to receive every 15 minutes, which increases CPU load and power 
consumption. Not great.

There are a few alternatives. The client could use protocols like PCP or 
UPNP-IGD to open a port in the local NAT. That's fine if the local 
router supports it. It can work very well if the network supports IPv6 
and the client just needs to set a pinhole in the local firewall. But it 
will not work if the local ISP is using some combination of IPv4 and 
Carrier Grade NAT. Unless the CGNAT supports PCP and the client has a 
plausible way to discover the address of the CGNAT. Maybe the IETF could 
work on that, but I am not holding my breadth.

Another way to reduce the impact on the client is to make sure that all 
applications doing keep-alive do it exactly at the same time. If they 
do, then the radio wakes up only once, sends a train of messages, maybe 
waits for the ACKs. Not perfect, but at least if preserves the battery a 
bit. Of course, that solution does not help the server at all.

Yet another solution that had been tried is to have a system level 
process do the keep alive on behalf of all applications in the box. I 
won't go in the details, but we could maybe do a variant of that with 
Masque. Have the client use Masque for all outgoing connections, 
connecting to a Masque server outside the CGNAT. Then the client only 
needs the Masque session alive -- 1 keep alive instead of N. The 
end-to-end QUIC session could use IPV6, and long idle timers. Maybe 
something we could actually ship!

-- Christian Huitema

On 9/1/2024 1:00 PM, Ian Swett wrote:
> This is a real problem, but I'm unsure what the best way to approach it is.
>
> I think you're suggesting that a large server operator could try to infer
> NAT timeouts for clients of different IP prefixes and communicate that to
> the client as a suggested keepalive/ping timeout?  I'm curious about how to
> infer NAT timeouts?  Our servers detect a dead connection, but I'm not sure
> how to tell what the reason is and more specifically the NAT timeout?
> Sometimes devices just drop off the network.
>
> As you may know, Chrome will send a PING as a keepalive after 15 seconds of
> idle only if there are outstanding requests (ie: hanging GETs).  The number
> was chosen somewhat arbitrarily and is certainly not optimal, but it did
> fix some use cases where hanging GETs were otherwise failing.
>
> Thanks, Ian
>
> On Wed, Jul 24, 2024 at 5:55 PM Martin Thomson <[e-mail]> wrote:
>
>> The intent of the idle timeout was to have that reflect *endpoint*
>> policy.  That is, it is independent of path.
>>
>> It's certainly very interesting to consider what you might do about paths
>> and keep-alives (or not).  But that's a separable problem.  Having a way
>> for endpoints to share their information about timeouts might work, but I
>> worry that that will lead to wasteful keepalive traffic.  How would we
>> ensure that keepalives are not wasteful?
>>
>> Is there a better way, such as a quick connection continuation?
>>
>> On Wed, Jul 24, 2024, at 11:24, Lucas Pardue 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?
>>>
>>> [1] - https://dl.acm.org/doi/10.1145/1879141.1879174
>>> [2] -  https://www.rfc-editor.org/rfc/rfc4787.html
>>> [3] - https://www.rfc-editor.org/rfc/rfc9308.html#section-3.2
>>> [4] -
>>>
>> https://www.ietf.org/archive/id/draft-ietf-quic-multipath-10.html#name-idle-timeout
>>
>>