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

ekr <notifications@github.com> Wed, 08 July 2020 01:39 UTC

Date: Tue, 07 Jul 2020 18:39:38 -0700
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4Z6CST4ZP3C2QA4EF5CECNVEVBNHHCN2JVQE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3844@github.com>
Subject: [quicwg/base-drafts] Which idle timeout are we avoiding in 10.2.2 (#3844)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f0523da527f6_2c033fd4dcacd9601103f7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/UesIKWDLnisP8xbyjmPhRV9SNxU>

> 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

[quicwg/base-drafts] Which idle timeout are we av… ekr
Re: [quicwg/base-drafts] Which idle timeout are w… Martin Thomson
Re: [quicwg/base-drafts] Which idle timeout are w… Martin Thomson