Re: [quicwg/base-drafts] How many probed paths should a server remember? (#3489)

Martin Thomson <> Thu, 12 March 2020 05:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 454803A0F8F for <>; Wed, 11 Mar 2020 22:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.482
X-Spam-Status: No, score=-6.482 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_DNSWL_HI=-5, 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 ZzqqTaBCH45W for <>; Wed, 11 Mar 2020 22:45:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D57F3A0F86 for <>; Wed, 11 Mar 2020 22:45:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7CC0226173D for <>; Wed, 11 Mar 2020 22:45:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1583991912; bh=PN0GBJWiZPkA2llOcazuEJoOQpT+AuQmGjNSNj+WBdM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=b/taw457Muc6yeCcjuAzt979+E4rs3MlEPuEfL9/j9Go/fOHx2H9jLAoI6ZtecK6c iY7vrKoBV6za+F11tMs3UiZNhvFgoWUNmpQYvirf3b3qPiBI+yL8ANygji0CTdTiUL Eo55YtH6L9kYzuNQA7FJJ3FqPYUhlVvvaS5NEES8=
Date: Wed, 11 Mar 2020 22:45:12 -0700
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3489/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] How many probed paths should a server remember? (#3489)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e69cc6837ab2_31893f80466cd9681705dc"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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, 12 Mar 2020 05:45:14 -0000

So a server doesn't need to probe in response to a client that probes a path, so it doesn't really have any state to attribute to probed paths.  A server can just respond to probes.  The cost to it, if it doesn't, is that it has to probe after a migration and that could have performance implications.

I would be happy saying that an endpoint ideally both probes and remembers the status of those probes for as many paths as it has issued, active connection IDs.  Probing paths and remembering the status of probes partly mitigates the reduction in CWND that follows migration, so there is a potential performance gain from keeping this state.  But the window is still likely reset, so the performance hit is essentially unavoidable either way.

The total number of paths a server might have to remember is limited by the active_connection_id_limit of the client, but it can be less (as you already noted), so the server has the ability to limit its exposure.

Thus, a server can probe and remember the status of as many paths as it likes.  I'd say that this is a fine piece of advice, but that's all it needs to be.  I agree that yet another transport parameter is not a great reaction to this relatively minor issue.

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