Re: [quicwg/base-drafts] Idle timeout needs more description and a recommendation (#2602)
Martin Thomson <notifications@github.com> Wed, 10 April 2019 00:43 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 5C31812013B for <quic-issues@ietfa.amsl.com>; Tue, 9 Apr 2019 17:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 UQX0mWwzzkhC for <quic-issues@ietfa.amsl.com>; Tue, 9 Apr 2019 17:43:42 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBCA120142 for <quic-issues@ietf.org>; Tue, 9 Apr 2019 17:43:42 -0700 (PDT)
Date: Tue, 09 Apr 2019 17:43:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1554857021; bh=XWyJCTOg+uAim+d4oo2JRcgHHmlugJwTNbz+8H3kkkk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=2T1Tpo5U2ba3Jx0mrPKZV8jlnhJbDedm7nlpbgzKbU4LWOk6lAEajOUGmgcIaCzGo Z7BOI2u1Nt3VEVgRc0AaBYReFzq7zFde+UN1EzkaDaOqtfFABqxOL1P1NNTUEUYWry JWfd20SgLt/01aYxNWz7o0LiYFlgS5Q7KPGzRs+o=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb77312ee9b80e2a850a73b6b31e35336dce2cdac92cebaba6ebd92a169ce19b4675e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2602/481490843@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2602@github.com>
References: <quicwg/base-drafts/issues/2602@github.com>
Subject: Re: [quicwg/base-drafts] Idle timeout needs more description and a recommendation (#2602)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cad3c3d1b5f9_75283fa3ea2d45c42400b5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/irPJC2GVjWAz6SC7GSFCDf-21uQ>
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: Wed, 10 Apr 2019 00:43:44 -0000
I disagree with this. In total, but for various reasons. Endpoints have their own rules about how long they are willing to wait, so any recommendation is a bad idea. The min(client, server) thing is not necessary. You might note that this is a natural consequence of the design, but this is a unilateral thing. If you want to wait longer, you can. This is particularly important in cases where connections are garbage-collected rather than reaped on a timer. In those cases, idle timeouts can be much longer on one end than the other if the short timer is GC'd. The endpoint that does GC might hold the connection alive much longer, and even initiate new activity on that connection well after its advertised timeout. This can be different to what endpoints might choose to do about keep NAT bindings alive. Keepalives are sent to keep bindings alive on paths and [we already have text on that](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#frame-ping). Paths are not connections. -- 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/2602#issuecomment-481490843
- [quicwg/base-drafts] Idle timeout needs more desc… Jana Iyengar
- Re: [quicwg/base-drafts] Idle timeout needs more … Martin Thomson
- Re: [quicwg/base-drafts] Idle timeout needs more … Jana Iyengar
- Re: [quicwg/base-drafts] Idle timeout needs more … Martin Thomson
- Re: [quicwg/base-drafts] Idle timeout needs more … Kazuho Oku
- Re: [quicwg/base-drafts] Idle timeout needs more … ianswett
- Re: [quicwg/base-drafts] Idle timeout needs more … Jana Iyengar
- Re: [quicwg/base-drafts] Idle timeout needs more … Kazuho Oku
- Re: [quicwg/base-drafts] Idle timeout needs more … MikkelFJ
- Re: [quicwg/base-drafts] Idle timeout needs more … Martin Thomson
- Re: [quicwg/base-drafts] Idle timeout needs more … Mark Nottingham
- Re: [quicwg/base-drafts] Idle timeout needs more … Mark Nottingham
- Re: [quicwg/base-drafts] Idle timeout needs more … Lars Eggert
- Re: [quicwg/base-drafts] Idle timeout needs more … ianswett
- Re: [quicwg/base-drafts] Idle timeout needs more … Martin Thomson