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

MikkelFJ <> Thu, 12 March 2020 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 933373A0990 for <>; Thu, 12 Mar 2020 14:13:59 -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 4-0IXO-Opp7m for <>; Thu, 12 Mar 2020 14:13:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49B1B3A098A for <>; Thu, 12 Mar 2020 14:13:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7A1F3660E48 for <>; Thu, 12 Mar 2020 14:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1584047637; bh=BwZ9S5QdHHLwpbmYmaM+rbRv9hjYH8mYCSZgEnFO08k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EfAojiPYyg+xiE8XYplYfTfN4+RMFstPz8cRZKESLW9qxdeFUnsgVVDdgzw3w1+Ru hz0q8epTe7A2u2ALYdppue6wi310/MY6fmCdDXuwD45367JeANMR1Y32yEYlL9EJuh sghU7Uky1VHMCmMsSR7NBDo7UB54Fc+4dLOqnDog=
Date: Thu, 12 Mar 2020 14:13:57 -0700
From: MikkelFJ <>
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_5e6aa6156a0ba_3fbf3f7e53acd96875684"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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:14:00 -0000

I tend to agree with Eric, but I think there are some aspects to consider:

You don't want to limit yourself to one extra path as Ian suggests because you might have 3 or 4 paths forward, e.g. sittig on Wlan 2.5GHz with optional 5GHz if the first becomes congested, along with a 4G and 5G modem path. You need to monitor these and choose the best path forward once the preferred path fails. Maybe this is a bit extreme, but just to illustrate path migration isn't linear.

At the same time, the peer need to issue enough IDs to not stall progress in addition to accommodating the number of paths forward a typical client might need. I'd say having double the number of CIDs in spare is probably OK, but maybe there isn't a need for a spare CID for every path. So it could be number of paths + 2 or something.

Thus, a recommendation could be that a client SHOULD not track paths beying having 2 spare CIDs and a server SHOULD be prepared to track the number of issued CIDs minus two, as a general rule. Exceeding that may require delayed probing which could lead to temporary delays.

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