IETF Logo Mail Archive

Re: [quicwg/base-drafts] Connection migration optional? (#1271)

Kazuho Oku <notifications@github.com> Mon, 09 April 2018 06:08 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 80D54126B7E for <quic-issues@ietfa.amsl.com>; Sun, 8 Apr 2018 23:08:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YfcDo_DzE_CB for <quic-issues@ietfa.amsl.com>; Sun, 8 Apr 2018 23:08:07 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875A21200A0 for <quic-issues@ietf.org>; Sun, 8 Apr 2018 23:08:07 -0700 (PDT)
Date: Sun, 08 Apr 2018 23:08:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1523254086; bh=a5vIM5NEoqI3g8vebOPGzp7GfyYoORLVk9uTkw5OMjA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Zd/i/H2MsAuUiGlTDpXCM3ER+9X6ZggSu1+rVt6hF0ZkR5BL/Nr264JgtaE+19oLZ TdMA/5IcFsTmvpBRUAPVmps8q2Uo/fc7rEIJkuv1XlmUJTMSmj19G7KC1wD+27yE5H jMrrdNdH5BdBsU9VbwQyOiun1YPJIoWI5IyphKJQ=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab0822b122a0df97a486f48d2e5c3c781d060f665892cf0000000116e2c54692a169ce129955d7@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1271/379643507@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1271@github.com>
References: <quicwg/base-drafts/issues/1271@github.com>
Subject: Re: [quicwg/base-drafts] Connection migration optional? (#1271)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5acb03469769c_a152ae2075e2ec814951d"; 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/bq1RPTTYp_pc5itmNCcqeAohArU>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 09 Apr 2018 06:08:10 -0000

I agree with what @martinthomson says.

A server can always decide to not send a `NEW_CONNECTION_ID` frame (it's not even a "SHOULD" even though some if not many of us anticipate that the server's sending it), and then the client would notice that there is no point in doing a gratuitous migration.

I also think that for the data-center use-case, nobody would object for QUIC connections not doing gratuitous migrations.

For the connections originating from the browser, I believe that a server that does not send a `NEW_CONNECTION_ID` frame should declare an idle timeout of somewhere below 30 seconds, so that the client would try to either keep the connection alive with no rebinding (by sending pings) or to reconnect in 0-RTT after quiescence that could have caused a rebinding.

-- 
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/1271#issuecomment-379643507

v2.23.0 | Report a Bug | By Email