Idle timeout editorial fixes #3444
Conversation
From @janaiyengar and @MikeBishop comments on #3099 Fixes #3184
ianswett
added
editorial
draft-ietf-quic-transport.md
Outdated
| 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. |
There was a problem hiding this comment.
This sentence doesn't really capture what the original text was attempting to explain. That is, the original text intended to explain that a reset on receipt is insufficient because local attempts to restart communication might still result in the idle timeout period lapsing. This says something different.
There was a problem hiding this comment.
I think the change is in response to my comment, 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.
There was a problem hiding this comment.
Thanks, I added back the original sentence, since as you point out, something was lost. PTAL.
| 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}}. |
There was a problem hiding this comment.
Perhaps clarify that it is the application that decides when to keep a connection alive.
There was a problem hiding this comment.
That's only true to the extent that the application controls what activity is generated. An application needs to communicate its intent.
From @janaiyengar and @MikeBishop comments on #3099
Fixes #3184