Re: [quicwg/base-drafts] Idle timeout editorial fixes (#3444)

[MikkelFJ <[e-mail]>]

mikkelfj commented on this pull request.



> @@ -2420,20 +2420,22 @@ close ({{immediate-close}}) if it abandons the connection prior to the effective
 value.
 
 An endpoint restarts its idle timer when a packet from its peer is received
-and processed successfully.  The idle timer is also restarted when sending
-an ack-eliciting packet (see {{QUIC-RECOVERY}}), but only if no other
-ack-eliciting packets have been sent since last receiving a packet.  Restarting
-when sending packets ensures that connections do not prematurely time out when
-initiating new activity.  An endpoint might need to send packets to avoid an
-idle timeout if it is unable to send application data due to being blocked on
+and processed successfully.  The idle timer is also restarted when sending the
+first ack-eliciting packet (see {{QUIC-RECOVERY}}) after receiving a packet.
+Restarting when sending packets ensures that connections do not prematurely time
+out when initiating new activity.  Only restarting when sending after receipt of
+a packet ensures the idle timeout is not excessively lengthened past the time
+the peer's timeout has expired.  An endpoint might need to send packets to avoid
+an idle timeout if it is unable to send application data due to being blocked on
 flow control limits; see {{flow-control}}.

Perhaps clarify that it is the application that decides when to keep a 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/pull/3444#pullrequestreview-363023786