IETF Logo Mail Archive

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

Tommy Pauly <notifications@github.com> Fri, 15 June 2018 02:06 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 63667128CF3 for <quic-issues@ietfa.amsl.com>; Thu, 14 Jun 2018 19:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.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, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 mdW_KzVzn2Bu for <quic-issues@ietfa.amsl.com>; Thu, 14 Jun 2018 19:06:28 -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 7D427127AC2 for <quic-issues@ietf.org>; Thu, 14 Jun 2018 19:06:28 -0700 (PDT)
Date: Thu, 14 Jun 2018 19:06:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1529028387; bh=s3XXcC75fHwimVMdCd/5tEV09BcRg+bHB2xYJ6smGxg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=w76FE+5+DI4jZy7y4C1LF2erUdddvZVUw2TpRttMoah0ZbiCd9fvwUFj7uNznejP9 qU3Mu0zYvn94v+1q34TmPdGMFZ1bGBZRBXf8VQhJuAUMKNt7XBSi2hEV92fLtL5bmM 6WX0aTndWwRjhfpBkbnKmMuQS9u72RwF5zkh1ks4=
From: Tommy Pauly <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abaf19ff5c0b18e481123151fa1110c87e51f2a78292cf00000001173ae12392a169ce129955d7@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/397492029@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_5b231f23c7ffa_340f3f9820726f801095d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: tfpauly
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/DHFOE4h_csxjsekwB7LGTSxf4gE>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 15 Jun 2018 02:06:31 -0000

If the option is explicitly to disable migration, and migration is assumed to be supported by default, I think the text can be written sufficiently carefully. We want to allow the default case for clients to work.

The peer-to-peer case of one peer being stuck behind a NAT, signaling that the other peer shouldn't migrate is an interesting point, and one of the points I find more compelling for not migrating automatically to the same address. It is a bit comparable to the NAT detection mechanisms used by IKE, which determine some later protocol behavior. Let's make sure to call out this scenario in the text, as well as others, perhaps specifying that deployments that don't fall into these scenarios in which migration is not useful SHOULD NOT disable migration, so as to encourage mobility of clients.

Doing the negotiation in the handshake as a TP is preferable to version indication in this case, I'd argue.

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

v2.31.3 | Report a Bug | By Email | System Status