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

Kazuho Oku <> Thu, 12 March 2020 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1753A3A0408 for <>; Thu, 12 Mar 2020 14:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Status: No, score=-1.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, 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 lj_Z4VwWsUMa for <>; Thu, 12 Mar 2020 14:28:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 308293A0789 for <>; Thu, 12 Mar 2020 14:28:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 607618C0BD9 for <>; Thu, 12 Mar 2020 14:28:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1584048513; bh=FznPbb73c3iOLonNBBuL13Mb9ysFpOXA6g79mEwyPZ4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FXfWthEd0YJCcNnzZAbeTBG//vrzVovkPOV13qjUOWlo+a3FNcpCOVOmsKYvpF022 mbWSPNcVPmjYR0lTCCQwDP+yMnU9ZehyTXCoA5Bv5FPUFkA7sEMjxs7kcVonzazlgY fzgUZftVKz1AXPyn+9TZLW5jRXlwXvZ3jikCXnTg=
Date: Thu, 12 Mar 2020 14:28:33 -0700
From: Kazuho Oku <>
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_5e6aa9814ea42_2d953f93f24cd9641278fa"; 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, 12 Mar 2020 21:28:40 -0000

I tend to agree with what @erickinnear says.

If I haven't been clear, I share the view that probably the best solution to this issue is to recommend servers to remember at most N paths, where N is the maximum number of active connection IDs it provides to a peer at any given moment.

I think @mikkelfj is correct in pointing out that the client might not use all the spare CIDs for probing, but I would argue that that can be a local decision of each client implementation. In terms of operational complexity on the server-side, the recommendation being N or N - 1 or N / 2 does not matter at all. Let's simply recommend N for the servers, and be silent about what clients should do.

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