Re: [quicwg/base-drafts] 5-tuple routing and SPA (#3608)

Kazuho Oku <> Wed, 29 April 2020 23:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC5F83A09F6 for <>; Wed, 29 Apr 2020 16:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Status: No, score=-1.696 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_IMAGE_ONLY_28=1.404, 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 kVh00ziaiuii for <>; Wed, 29 Apr 2020 16:25:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25EBC3A09F1 for <>; Wed, 29 Apr 2020 16:25:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BA5372C172F for <>; Wed, 29 Apr 2020 16:25:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1588202738; bh=ZTRohLwSoICxSm3uf7I29yFj7BJ+LmDFBaebcrd8oLE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GaIyF6XQleJSx1cRJWCvhrdqlTptlVuCtzK6K7iGCdm+RuU/sFHetnpn1dP6ESzj6 HCVC6P3fHsWEOkNxYsC9qTPz4NTnakd68qPNGx8HbDim9DVfvU+p1yiC0F9cnhviq8 8mgbedUxWfy8c8i9SdoM8prkDrRdybUz+DgaYAio=
Date: Wed, 29 Apr 2020 16:25:38 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3608/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] 5-tuple routing and SPA (#3608)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eaa0cf2ab1ea_33773fa626ccd95c2456b3"; 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, 29 Apr 2020 23:25:43 -0000

> Should we blanket recommend that clients not actively migrate if they ignore / are unsuccessful in using the SPA? Or should there be a way for the server to indicate that?

I do not like the first option, because IMO banning migration on the original address is a premature optimization based on what we have now, has negative effect on what we would have in the future.
My assumption is that the majority of the server deployments would be CID-aware, especially in the long term, especially in terms of traffic volume. Note that the volume of traffic is more important than the number of server deployments, as migration is about (improving) end-user experience.

IMO there are two ways forward:
* (a) State that disable_active_migration TP only applies to the original address. Per-definition, server-preferred address is an address that is capable of receiving packets from any address. There is no need to prohibit clients doing migration when connected to SPA.
* (b) Do nothing. Clients are RECOMMENDED to implement SPA, and this issue is about a small fraction of deployments that rely on non-CID-aware load balancers. We can ignore the problem.

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