IETF Logo Mail Archive

Re: [quicwg/base-drafts] Migration before handshake completed is very messy (#2309)

erickinnear <notifications@github.com> Mon, 07 January 2019 05:28 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 3282212D4E9 for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 21:28:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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 5pIb7TGkzyIT for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 21:28:40 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC8C128D09 for <quic-issues@ietf.org>; Sun, 6 Jan 2019 21:28:40 -0800 (PST)
Date: Sun, 06 Jan 2019 21:28:39 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546838919; bh=g48jwQE9W3M1EirApGdSFJD4aT34vn/W4PJUar5i8xk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=c3pB+zNQREoQvxg1keENVgMvIIMOh6oPDNG8UClmIKpj5ZMNSoUGrU2BCNzCIzm6x gSRsx12z7sYT6Gcrams5cfgjSPQX8wIXM3rklw6rXCdWi9fuNOP9RUOFlK0MAUssR1 8krIq4seyjVBI/8KrdG0WUFmhfVJk4jCDfXwZrHA=
From: erickinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab5522e5ba849c30a50f91f254689e532c1408765d92cf00000001184aa58792a169ce179fc90b@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2309/451825917@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2309@github.com>
References: <quicwg/base-drafts/issues/2309@github.com>
Subject: Re: [quicwg/base-drafts] Migration before handshake completed is very messy (#2309)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c32e3874d2a4_45bd3fbe02cd45c41463ad"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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/KSvo6HAT6sHsLwPZUVDVN6989Dk>
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: Mon, 07 Jan 2019 05:28:42 -0000

I think stating that endpoints should not initiate migration before the handshake is fully complete would make a lot of sense. 

In addition to reducing the potential for added complexity around those interactions and the handshake, it seems like the need for migration at that point in the timeline can mostly be satisfied by a new connection on an alternate path.

If we don't have a lot of activity happening yet on the connection (although interesting thought about the NEW_CONNECTION_ID frames), it seems like you don't really lose a whole lot by opening a new connection instead of migrating a pre-connected connection that hasn't otherwise been used.
That makes me less concerned about when the threshold 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/2309#issuecomment-451825917

v2.23.0 | Report a Bug | By Email