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

Jana Iyengar <> Tue, 19 May 2020 21:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E30F3A1161 for <>; Tue, 19 May 2020 14:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Status: No, score=-1.697 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, 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 takvopR5wCUA for <>; Tue, 19 May 2020 14:34:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7402B3A1160 for <>; Tue, 19 May 2020 14:34:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4ABC26E0326 for <>; Tue, 19 May 2020 14:34:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1589924065; bh=vblhB1SrbKf6cKx74DJjTN14bPij16F6gDQuORy5WoI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=cN6+cqGsjEQ6nmXzx46nbj+473TgnIYzsgdHtel0d9JQ08CORr1YNFD058xDEnDWG tJVsLNrhuQ173fn8PUdgdMb+BfvQnH6KcoZ/pQq1rD8QkUGvM4w8BAlu9MCprgmSgz wz59F6mSVFN2Vk58MmzkjDBU5WpESupczPPiFG2E=
Date: Tue, 19 May 2020 14:34:25 -0700
From: Jana Iyengar <>
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_5ec450e13a1a7_a873fa5f2acd9602509cf"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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, 19 May 2020 21:34:28 -0000

This conversation has made it clear to me that an address, and not a server, is the thing that supports client migration. Which makes sense -- migration support at the server is entirely a question of routability, and it makes sense that it would be tied to the address in question and not the endpoint. So *if* we were to do anything, I think I would propose: 
- scoping disable_active_migration to the handshake address, and
- adding two disable_active_migration flags to the preferred_address TP, for the two addresses in the TP.

That said, this is a clean enough extension. A new extension can define a new TP that provides this granular interpretation of the three server addresses. A server that wishes to support this can send both the SPA and this newSPA TPs, with the SPA TP (with the current scoping of disable_active_migration applying to all server addresses) providing cover for legacy clients.

Also I expect that clients are likely to switch to using the SPA if provided. A server that has different routability properties for the two addresses can wait for some deployment and make decisions on whether to risk allowing migration based on data of what it sees as client behavior with SPA.

I would argue for doing nothing now. Experience will teach us the right way forward. If necessary, this extension will be easy enough to do, and importantly, the current interpretation of disable_active_migration gives us the right kind of cover in the meantime.

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