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

Kazuho Oku <notifications@github.com> Wed, 17 June 2020 23:42 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4AE3A0CE6 for <quic-issues@ietfa.amsl.com>; Wed, 17 Jun 2020 16:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvoQt5akVk_l for <quic-issues@ietfa.amsl.com>; Wed, 17 Jun 2020 16:42:10 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5943A0CE2 for <quic-issues@ietf.org>; Wed, 17 Jun 2020 16:42:10 -0700 (PDT)
Received: from github-lowworker-1ac52d7.ash1-iad.github.net (github-lowworker-1ac52d7.ash1-iad.github.net [10.56.25.52]) by smtp.github.com (Postfix) with ESMTP id 6BE4D6E01AF for <quic-issues@ietf.org>; Wed, 17 Jun 2020 16:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1592437329; bh=xOXqjdSbt/xaTmwopPJVYLOHRKdgmEIGNt/0Efyo1TA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=aaLq27za7JquwZz/GGVLad2DQg/hm4PqjPrChOFZnGqkqzs6qd4cy2CPFlehWCwXo UsL1dt09fKk1aBomHtYiXsC6B7/DKif2/X1lTZBr/hn9RiGwKxgnki8LvnsvQYJgMf xYelHnloiKu/wDyyxjvCdRomTrTy/XEVBcH2ptpE=
Date: Wed, 17 Jun 2020 16:42:09 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3K2SYBYZATGQYUQIN462FVDEVBNHHCMFSQTA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3765/645682509@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3765@github.com>
References: <quicwg/base-drafts/issues/3765@github.com>
Subject: Re: [quicwg/base-drafts] disable_active_migration with SPA (#3765)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eeaaa515bf22_411a3fa35e4cd95c16564b"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Nw7n4lEYcf4VdOJfdpn6B3xWqDQ>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 23:42:12 -0000

> And then there is still another case -- using an anycast address as the handshake address and landing on a server deep inside your provider network. You will want to use SPA to avoid a risk of anycast route change during a long-lived connection.

Could you please elaborate why it is beneficial to migrate from an anycast address to SPA in this particular case?

It is my understanding that this is about a server located in an ISP network, hosting an anycast address and a preferred address. I would assume that that server is only reachable from client within that ISP, regardless of the address being the anycast address or the preferred address.

Assuming that is the case, migrating to a preferred address does not improve the chance of *each connection* surviving across unintentional client address migrations. Regardless of if the client uses the original address or the preferred address to designate the server, the connection survives while the client stays in the ISP network. If it goes out, then the connection dies regardless of the server address being used.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3765#issuecomment-645682509