Subject: [quicwg/base-drafts] Idle Timer Can Fire Even with Outstanding Data to Send (#2744)

From: Nick Banks <[email-masked]>
Date: Wed, 22 May 2019 03:27:08 -0700

If a connection gets send blocked for long enough (i.e. the peer application isn't draining the data right now, and thus not giving more flow control credit) the idle timer will fire. This is because no data is being sent over the wire while the sender is blocked. To me, it seems that we shouldn't consider a connection as idle if the application is actively trying to send.

While in this blocked state, should the transport periodically send some ACK eliciting packet to keep the connection alive?

-- 
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/2744

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 03:38:30 -0700

It is not much different from being blocked because there is currently nothing to send. The timeout will clean up connections that do not make progress. If the application is happy with waiting a very long time to proceed, it could send pings, but it might as well want to call it a day. So I'm not sure the spec needs to say anything about that. We are talking about 10 minutes of no progress by default.

-- 
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/2744#issuecomment-494749141

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 May 2019 07:41:27 -0700

It seems reasonable to use a keep-alive.  If you have something you want to use the connection for and you aren't able to maintain activity on the connection, then either poke it or - more likely - give up.  I don't think that we need a design change for this, but if you want to write some text, I wouldn't be opposed to taking a look.

-- 
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/2744#issuecomment-494832793

---

From: Nick Banks <[email-masked]>
Date: Thu, 23 May 2019 03:10:51 -0700

Thinking about this, another solution would be to continue to send a *blocked frame, while in the blocked state. Even if the peer acknowledged the first blocked frame, if you're still blocked, you send it again. Personally, for my implementation, this would be the easiest thing to implement.

I don't think the spec should make any requirements in this area, but I do think it should call this problem out and possibly make a recommendation.

-- 
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/2744#issuecomment-495156791