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

Igor Lubashev <> Tue, 14 July 2020 00:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F8D83A097E for <>; Mon, 13 Jul 2020 17:00:41 -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 rHAKz2allKct for <>; Mon, 13 Jul 2020 17:00:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A25223A100D for <>; Mon, 13 Jul 2020 16:59:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF0688C11E2 for <>; Mon, 13 Jul 2020 16:59:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1594684787; bh=zgSA01MfGSLh5vH+Cptp6NZYlAaDUWcoDQyMjyHkez8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=WD2ixqNB1xMsIh504mbDufAQiC5Yz/AcNWGdjs+7uGsFncu8q0XBmmadQCWWUqWXL KvCQJ3JmLq0hKeSnsA5ClnPfmBxOqmojcKNS54Ab+K5gCaSpV5HLvrrffli+TKSIJV OFNRQRVCTYXt5xmjWDFsnq9fHqQao2j8VOi7Q3Dg=
Date: Mon, 13 Jul 2020 16:59:47 -0700
From: Igor Lubashev <>
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_5f0cf573de990_33593fb6088cd9641473512"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: igorlord
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 00:00:41 -0000

Making `disable_active_migration` a property of an address allows for a lot of flexibility to innovate with routing and load-balancing and network deployments.  So +1 here.

> not all migrations need to be to a different network attachment

Except for a change to an address in another IP family, a different network attachment is by far the most common case to actively change to another IP address.  If the client knows that it is not changing the network attachment in a way that is relevant to the server, it can try to ignore the `disable_active_migration` hint on the SPA.  I think it is correct to have all normative language regarding `disable_active_migration` a SHOULD, since unintentional migrations will happen.

> if you take the most common case of this, a CDN node embedded within an ISP's network that isn't accessible from other networks, then the client can happily migrate all it wants within that ISP's network.  If it tries to probe (or even migrate if there are no other options) from a different network attachment, then it will simply see the server as not accessible.

If the CDN node is, indeed, inaccessible from outside of the network, the client would be burning an rtt (or some timeout).  However, the node may actually be accessible from outside of the network, but have a poor performance from there.

Theoretically, I can see a case of some large enterprise campus creating a network with dozens of access points, all acting as independent NATs, and someone running around constantly connecting and disconnecting from the APs, getting new addresses with each AP migration.  But who actually builds networks like that?! It is much more likely that your address will stay with you for as long as you are connected to that network.  For someone running around a large campus, getting a new address on their device will pretty much only happen when they lose WiFi and reconnect via cellular (or hop on a bus via WiFi onboard) -- neither are likely be to great for the original embedded CDN node.

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