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

Kazuho Oku <> Thu, 21 May 2020 04:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3FDF3A0AB2 for <>; Wed, 20 May 2020 21:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Status: No, score=-1.483 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_24=1.618, 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 hEr2ZnPbnYRK for <>; Wed, 20 May 2020 21:20:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 144763A0AAF for <>; Wed, 20 May 2020 21:20:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 139E56E1189 for <>; Wed, 20 May 2020 21:20:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1590034843; bh=iUwmL/suzhvTdeSIeTvvZom5Rbde19PKUMF/4xK6/DY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=f2rzrAFQG2OvsQ8yRYqr9x1pyrhAit5W7Ths9fANQtMfS4oM7CVt4KvmZqc60NdCX hpppFbqNcKkfP5tflKMwqKAJBfUSPaITbO4i4ESHmhRLi75yM5U2JiwCg0FCO6J0CJ 49CxpB2v599gB7+eP1T90XPD4W+pFtxgDDzuNi1M=
Date: Wed, 20 May 2020 21:20:43 -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_5ec6019b4a4f_5eb23fcb1b8cd96446991a"; 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: Thu, 21 May 2020 04:20:46 -0000

> It assumes that migration is more likely to succeed when attempted to the preferred address as opposed to the handshake address. While this assumption might hold in some server deployments, it is not a fact.

Would you mind elaborating why a server, accepting connections on a preferred address, might not be able to disambiguate connections using CIDs?

As stated previously, when a client migrates to the preferred address, the client's address port tuple can change due to the existence of NATs. A server using preferred address need to take that into consideration. That means that a server has to disambiguate connections based on the CID, which in turn means that the server would be possible to support migration.

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