Subject: [quicwg/base-drafts] Idle timeout needs more description and a recommendation (#2602)

From: Jana Iyengar <[email-masked]>
Date: Tue, 09 Apr 2019 17:37:32 -0700

As it stands, the idle timeout period is used by both QUIC endpoints, and may be made available to the application but,
- it's not clear how an endpoint should determine this value,
- it's not explicitly stated that the min(server, client) should be used,
- it's not explicitly stated that this min value should be communicated to the application, which needs it to determine how often to send PINGs.

A straw proposal is to use 30 seconds as the default idle timeout period, and state the other two points explicitly in the transport and http drafts.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2602

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Apr 2019 17:43:41 -0700

I disagree with this.  In total, but for various reasons.

Endpoints have their own rules about how long they are willing to wait, so any recommendation is a bad idea.

The min(client, server) thing is not necessary.  You might note that this is a natural consequence of the design, but this is a unilateral thing.  If you want to wait longer, you can.  This is particularly important in cases where connections are garbage-collected rather than reaped on a timer.  In those cases, idle timeouts can be much longer on one end than the other if the short timer is GC'd.  The endpoint that does GC might hold the connection alive much longer, and even initiate new activity on that connection well after its advertised timeout.

This can be different to what endpoints might choose to do about keep NAT bindings alive.  Keepalives are sent to keep bindings alive on paths and [we already have text on that](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#frame-ping).  Paths are not connections.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2602#issuecomment-481490843

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 09 Apr 2019 18:04:35 -0700

The recommendation is not for how long an endpoint is willing to wait, but a default recommendation for general purpose QUIC implementations. We have default recommendations in both the transport and the recovery draft based on best known practices. My suggestion for using 30 seconds as the default is based on GQUIC experience.

The min() thing is important IMO. Again, this is not a requirement, but keeping and trying a connection _after_ you believe the peer to have closed it potentially wastes an RTT.  HTTP connections using TCP do this all the time, and incur an RTT of delay. I'm not suggesting that we don't accommodate implementations that want to keep connections open for past the timeout period, but it's worth explicitly noting the cost of using a potentially dead connection. For an unconstrained implementation, what value do you see in continuing with a connection after it is likely to have been discarded by the peer?

Endpoints need to keep not only NAT bindings alive but also potentially QUIC state at the peer alive. If a server is taking time to generate a response and there is a risk of the idle timeout closing the connection  before the server sends a response. The application (HTTP) knows this, and is expected to send PINGs to keep the connection open, but without knowledge of the idle timeout at the peer, it has to guess how often to send a PING.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2602#issuecomment-481494142

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Apr 2019 19:20:19 -0700

Yep, don't think we need to recommend anything.

min() is not helpful except as a warning - and we already have that warning.

Keepalive is an entirely different thing.  Applications might decide to engage keepalives to keep paths active, or the connection as a whole, but the model should be that the application asks the transport to stay active and the transport manages that (because only it knows about multiple paths and so on).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2602#issuecomment-481507604

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 09 Apr 2019 20:52:56 -0700

> min() is not helpful except as a warning - and we already have that warning.

I think we have a corner case.

Consider a case where the server advertises idle-timeout of 10 seconds and the client advertises 5 seconds. Should a client use a connection that has been idle for 6 seconds to send new requests?

The client should, if we require servers to keep the connection state open for the timeout _it_ advertised (i.e. 10 seconds) regardless of the value advertised by the client.

The client should not, if we think that the server are allowed to drop the connection after min() seconds.

Do we clarify which way the server behavior in this example should be?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2602#issuecomment-481522853

---

From: ianswett <[email-masked]>
Date: Wed, 10 Apr 2019 11:06:09 -0700

@kazuho makes a very good point.

If we're ok with the server looking at the client transport parameters and sending an idle timeout in it's transport params that may be a function of the client's, then this may not be a real issue, but if we truly want transport params to be unilateral advertisements, then this is a problem.

I agree that the NAT timeout issue is totally separate, and I'd like to keep this issue away from that if possible.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2602#issuecomment-481800230

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 10 Apr 2019 13:50:14 -0700

I like @kazuho's formulation of the min(), but I don't think we need to state what the server or client _should_ do, rather we note the cost of using a dead connection. (I'm not opposed to saying that the endpoints _should not_ use potentially dead connections, but I don't think it's necessary.)

The discussion on PINGs is not about NATs, to be clear. The text we have right now on keeping connections alive with PINGs leaves it up to the application to decide when to send a PING. Without knowing when this connection might be closed by QUIC underneath due to an idle timeout, when should the application send a PING? 

I believe there's a problem here that QUIC "negotiates" its idle timeout with the peer (I know @martinthomson doesn't agree, but an endpoint does need to figure out how to use the peer's value), and HTTP is expected to keep the connection alive based on whether requests are pending or not, but we don't talk anywhere about the interaction between the two.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2602#issuecomment-481860087

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 10 Apr 2019 21:04:45 +0000 (UTC)

> I like @kazuho's formulation of the min(), but I don't think we need to state what the server or client should do, rather we note the cost of using a dead connection.

To clarify, my point is that the logic and endpoint uses for detecting a potentially dead connection depends on if the peer is allowed to use min() for determining how long the connection state needs to be maintained by the peer.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2602#issuecomment-481864886

---

From: MikkelFJ <[email-masked]>
Date: Wed, 10 Apr 2019 14:09:38 -0700

Conflating keep-alive with timeout is problematic due to hysteresis. You need to send keep alive at perhaps half the timeout interval, and if you do, the connection will not timeout, which is against the idea of a timeout.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2602#issuecomment-481866435