Re: [quicwg/base-drafts] disable_active_migration with SPA (#3765)

Eric Kinnear <> Tue, 14 July 2020 18:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B7393A0848 for <>; Tue, 14 Jul 2020 11:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.101
X-Spam-Status: No, score=-3.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2nUMGcfh_HMO for <>; Tue, 14 Jul 2020 11:31:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F296F3A0847 for <>; Tue, 14 Jul 2020 11:31:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 26FF3E1130 for <>; Tue, 14 Jul 2020 11:31:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1594751510; bh=dRX3OuL39nuuy+qCIRBg6z/sCYGIn4kb+6lS3gtyjfY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PpPGv9xMnM25+ccuYXveO/PmY3WncV6ogbNlwcgWidKpnTk0btMwIMisvSGFH7kqo d2laOC01O9ciTw6dhvvet84trqeKW76pPPx1uVkycF1/ZVy3H2gyR5cpyWo+BNTg62 6qMirRuPUwD9IuDu3ElLfP/Wsi7bIx318S/LJ7AQ=
Date: Tue, 14 Jul 2020 11:31:50 -0700
From: Eric Kinnear <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3765/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] disable_active_migration with SPA (#3765)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f0dfa1617207_437a3ff3110cd96c125851"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekinnear
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Jul 2020 18:31:54 -0000

I think I have a very different perspective on what @igorlord is saying above. From my perspective, if I'm 95% of the way done fetching a resource that I would need to restart from the beginning, I'm more than willing to have a suboptimal experience finishing that 5% than start over from the beginning. I would imagine that network attachment changes will result in the following behavior: 

1. Migrate currently active (not idle) connections to the new attachment
2. Bring up new connections from scratch on the new attachment for new requests
3. Transition everything we can to those new connections and close down the old ones once their transfers have completed
4. Have some threshold (likely bytes, but maybe percentage) beyond which we will just use the new connection and not the migrated one if it's not providing equivalent performance to what we had before

Prohibiting us from migrating here (especially in the embedded CDN node case) is probably something that we should discuss elsewhere as it's a bit orthogonal to this topic.

However, I think the key here, as we talk about use cases that are important to handle and cannot be handled via an extension, is that I don't think `disable_active_migration` was introduced to be an advisory "you probably shouldn't try to migrate because I don't think you'll have a good time if you do", we were pretty clear that this was a "disallow this, if you do it we will ignore your packets and that might break your connection". Clients are already expected to probe (if they can) and use those measurements to make good choices, it's already understood that some network topologies might result in a bad time if you attempt to migrate, and often the choice will be between a connection that's going to fail vs. a suboptimal connection.

Someone who doesn't want to allow migration to a different network attachment can simply ignore the probing packets that come in from those other attachments. Prohibiting migration entirely (or building a whole new scheme for prohibiting different types of migration) seems quite excessive in that case.

To summarize: 
- While I think it would be fine to generalize the "disable_active_migration" flag to cover SPA per-address as well, I don't think that we need the additional levels (although thank you @MikeBishop as it's really nice to see them listed out) outside of an extension. 

- Again, that's _if_ we decide there's a reason to do something other than the consensus already reached.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: