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

Kazuho Oku <> Wed, 17 June 2020 09:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10BF03A083C for <>; Wed, 17 Jun 2020 02:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Status: No, score=-3.1 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, 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 pI_xWkwXfVnC for <>; Wed, 17 Jun 2020 02:22:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA3B43A083A for <>; Wed, 17 Jun 2020 02:22:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 110841212C1 for <>; Wed, 17 Jun 2020 02:22:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1592385761; bh=EQoWXC4NsLaPF4NMDE5mANghJsiH8nTj4KN9hJ78VgU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PDIUkLHwqX3zOMP3ppA4QPgtQfWWBliEUJ1ECs9lrGTwXEX1t96jom6TB1ZlxrabF e9nqllc5uUgTn5M/SsivdAhJji6diJbpp+qi9k5VuMFOvWyvbJHvgdQrTYdg/Fmyxu V1w3OKJk/5tqKjw7mgAJtbTFqHm9p9FvvrR85p3g=
Date: Wed, 17 Jun 2020 02:22:40 -0700
From: Kazuho Oku <>
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_5ee9e0e0bf617_4aa73fe42c6cd964128989"; 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
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: Wed, 17 Jun 2020 09:22:43 -0000

@igorlord To me the description of the problem that you stated in helped me better understand what you are concerned about. Thank you for providing them.

Though I tend to wonder if we'd really want to use SPA in such case.

The rationale behind SPA is that providing a *preferred* address improves reachability. In the past, we considered two cases. The first one is when an anycast address is used as the handshake address. Then, switching to a unicast address is preferable, as it improves reachability. The second case that we considered is when a legacy load balancer that can route packets only by looking at the 4-tuple is being used. In such case, letting each backend server provide its own address as the preferred address improves reachability.

But in the scenario that you describe, I am not sure if the preferred address would provide better reachability than the original address. If that is the case, wouldn't it be sufficient to continue using the original address throughout the lifetime of the connection?

Or is your case specifically about using SPA to bypass the legacy load balancer in an environment that has reachability issues with the preferred address too? If that is the case, I can understand the concern, and I would not oppose to having a new signal, either within QUICv1 or as an extension. Though I would oppose to changing the current definition of `disable_active_migration`, as it sounds to me like a corner-case of a corner-case.

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