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

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> @@ -2420,20 +2420,21 @@ 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
-flow control limits; see {{flow-control}}.
+and processed successfully.  The idle timer is also restarted when sending the
+first ack-eliciting packet (see {{QUIC-RECOVERY}}) after receiving a packet.
+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.

I think the change is in response to [my comment](https://github.com/quicwg/base-drafts/pull/3099/files/e4dd819fb3939e82c668b52076f7d89d500b8e3f#r340837260), that you also need to clarify why it's not sufficient to reset it on every packet you send.  Basically, we've chosen a more complicated condition than "on receive" or "on send," and we should justify why the simpler conditions don't work.

-- 
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#discussion_r378465590