Subject: [quicwg/base-drafts] Which idle timeout are we avoiding in 10.2.2 (#3844)

From: ekr <[email-masked]>
Date: Tue, 07 Jul 2020 18:39:38 -0700

> An endpoint might need to send ack-eliciting packets to avoid an idle timeout
if it is expecting response data, but does not have or is unable to send
application data.

However, you can't necessarily reset your own idle_timeout that way because it only is reset when you haven't already sent an ack-eliciting packet after the last received packet. If this is about resetting the peer, then maybe editorial. If it is about resetting yourself, then this may be design.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jul 2020 18:56:24 -0700

This is both idle timeouts.

The idea behind the rules regarding the local reset of the idle timer is that if you send an ack-eliciting packet, you will get an acknowledgment.  You are required to send probes until you do.  So you only reset the timeout on the first.

-- 
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/3844#issuecomment-655233726