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

Igor Lubashev <> Tue, 14 July 2020 21:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F2423A07B7 for <>; Tue, 14 Jul 2020 14:54:24 -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 28TyHIdfZFrV for <>; Tue, 14 Jul 2020 14:54:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAC4A3A07B9 for <>; Tue, 14 Jul 2020 14:54:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 032396E0050 for <>; Tue, 14 Jul 2020 14:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1594763662; bh=BzwbgawIf0u7XtQUY5rEGd1o58Kcy+vlNtk/Ks5lVtw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=WbDBcrvMoUb0tiIpdo+MO5Fx2jPa6no1D0n148uDBbuy+XZx4wM2/95FeGlQZ1GeK wKK3qT85aES0C2svac/0bD9HR1vx6m0ewWons2ZwkJh+GcfMTQo858jOAoTxBOHDG4 4m4lL/k5qeUhV96deIEzy6n0dPJZapplyp0e/9jM=
Date: Tue, 14 Jul 2020 14:54:21 -0700
From: Igor Lubashev <>
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_5f0e298de4da7_6f833fb7076cd95c17142a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: igorlord
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, 14 Jul 2020 21:54:24 -0000

@ekinnear Thanks for a great discussion of the issue.  I agree, there are few problems that cannot be solved with a robust "happy eyeballs" implementation.

I'd say that if your client implements such "happy eyeballs" for every migration, establishing a new connection as well the migrating the original one, you do not need `disable_active_migration` in any of its forms.  I wonder what benefit `disable_active_migration`  can possibly offer for a robust "happy eyeballs" client like that.

But what are less sophisticated clients supposed to do?  I am thinking of clients that have only one connection to each host open at a time.

You say that you would prefer to finish downloading those 5% of the object from a slow server.  But what if that server knew that it would not serve any bytes to a client located in a different network (legally prohibited)?  Would you care to know about it before the migration?  How would that server let you know (either, ideally, before the migration or after the migration w/o forcing you to time out)?

The current text says that after a receipt of `disable_active_migration`, the client MUST NOT migrate, but it does _not_ say that the server "will ignore your packets".  Instead, it says that the server may either drop packets or proceed with the path validation and allow the migration.

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