IETF Logo Mail Archive

Re: [quicwg/base-drafts] Idle timeout needs more description and a recommendation (#2602)

Kazuho Oku <notifications@github.com> Wed, 10 April 2019 03:52 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 6592D1202F9 for <quic-issues@ietfa.amsl.com>; Tue, 9 Apr 2019 20:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 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] 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 56kNVf9tvEEc for <quic-issues@ietfa.amsl.com>; Tue, 9 Apr 2019 20:52:57 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ADC712022D for <quic-issues@ietf.org>; Tue, 9 Apr 2019 20:52:57 -0700 (PDT)
Date: Tue, 09 Apr 2019 20:52:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1554868376; bh=NWj7hwuqa2YdjpICDiDeOVdMnebOaRxi5DaPz/B83bk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=U9zKH0RYiopPu054cqYvJgGSDV6XNzr9B8hZaivwLsmg9NLSLN5ZWENC1f0QHfRh6 QhAO+5oLVbehfMO9bYifCL4N90rDKkDKRuKLk6dHsO+AObk/KEpKNP86KhLEzHP5Hv lzWiGezOtHHsbgC5iHqWNSpJR8O5FGCVUX8ZgKCw=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6f3a305fea75704d04d4202531b4a95de7852e1292cebaba9b1892a169ce19b4675e@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/481522853@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_5cad689811065_63183ffb600d45bc804e8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/_jOGZaSSc5nb2ls-82NYDe0Uwes>
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 03:53:00 -0000

> min() is not helpful except as a warning - and we already have that warning.

I think we have a corner case.

Consider a case where the server advertises idle-timeout of 10 seconds and the client advertises 5 seconds. Should a client use a connection that has been idle for 6 seconds to send new requests?

The client should, if we require servers to keep the connection state open for the timeout _it_ advertised (i.e. 10 seconds) regardless of the value advertised by the client.

The client should not, if we think that the server are allowed to drop the connection after min() seconds.

Do we clarify which way the server behavior in this example should be?

-- 
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-481522853

v2.23.0 | Report a Bug | By Email