[quicwg/base-drafts] What resets idle timeout? (#2149)

ekr <notifications@github.com> Thu, 13 December 2018 19:32 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BF2130E36 for <quic-issues@ietfa.amsl.com>; Thu, 13 Dec 2018 11:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.459
X-Spam-Level:
X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE8pazXbTmT7 for <quic-issues@ietfa.amsl.com>; Thu, 13 Dec 2018 11:32:36 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A2D130E34 for <quic-issues@ietf.org>; Thu, 13 Dec 2018 11:32:36 -0800 (PST)
Date: Thu, 13 Dec 2018 11:32:35 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544729555; bh=RNITpADkRdwjFGX8UDygGqg1GnvGH7rdpZINJC9clpI=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=yKS7zILYMjbKe5xbtBc9HbJML9Wwp9SUZvMHlI7gIaKa6ZAB/Yx3cth81qkS8BGIW 2n95FrNcD5+PPWL+eUdS/6bVteSyfG25Lj99E4DLYnMCtwj8zeFVuucRJSXuOBMrz/ XR/FekKWRI7UMSIG6t+aB9dth+w1g+aQGV285kto=
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abc114a0e44a394a197f235dc7c95751e3e865c0db92cf00000001182a75d392a169ce174b8a33@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2149@github.com>
Subject: [quicwg/base-drafts] What resets idle timeout? (#2149)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c12b3d3d28f5_34453fcb8b2d45c41178f3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/x40SI9nAILx3KTLvs0Z_vNNHYS4>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 19:32:39 -0000

```
Each endpoint advertises its own idle timeout to its peer. The idle timeout
starts from the last packet received.  In order to ensure that initiating new
activity postpones an idle timeout, an endpoint restarts this timer when sending
a packet.  An endpoint does not postpone the idle timeout if another packet has
been sent containing frames other than ACK or PADDING, and that other packet has
not been acknowledged or declared lost.  Packets that contain only ACK or
PADDING frames are not acknowledged until an endpoint has other frames to send,
so they could prevent the timeout from being refreshed.
```

I find this pretty hard to read, but assuming I *am* reading it corectly,
it basically says that if you read any packet or write any packet that
has a frame other than ACK or padding, then you reset the timer. The text
about "other packet has not been acknowledged or lost" doesn't make sense
unless you have some very complicated timer scheme, because the packet
won't be acknowledge or lost until after it is sent, at which point I
have already reset the timer. 


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