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

Eric Kinnear <> Thu, 12 March 2020 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E12B13A07B9 for <>; Thu, 12 Mar 2020 12:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Status: No, score=-3.1 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_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 balyVQQbh_Kh for <>; Thu, 12 Mar 2020 12:33:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDE143A0787 for <>; Thu, 12 Mar 2020 12:33:10 -0700 (PDT)
Date: Thu, 12 Mar 2020 12:33:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1584041589; bh=bnFYlUv4ITROkS5CWI3MrPRvNI5J/aHUKXmCSP138sk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=OuYYa5czJ+AE5UIQzJodOBOXn+RXoti0eLCBuXafHB7HUE8zfZCtjm8OhL0ilHUuM qxGhItrdL1U6r+ja6poWx/zbHDeg51cx2P47xOFCLSxDLAXXkYPEMezPVs4fu+aemu fTPwMnCBP0a+3qDU/JwxDebh1RDJWfMprrwAvl5I=
From: Eric Kinnear <>
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_5e6a8e75d3b21_13c13fbea4acd9685195df"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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 19:33:20 -0000

I don't think migration vs. multipath is currently the distinction for how many paths a client probes, it's the restriction on how many paths the client _uses_ at any one time, and I think that's appropriate. There are many cases where I'd want to be able to probe more than one path, and assuming that a device has a single network attachment (where we need to include IPv4 and IPv6 as more than one given that you need a new CID for each local address) doesn't make sense either.

The number of paths that a client can probe simultaneously is limited by how many CIDs the server is willing to issue to that client. 

To the point of the original issue: 
> Instead of recommending servers to remember paths as much as the number of spare connection IDs that they issue, we can introduce a transport parameter that caps the number paths that a client may probe. But IMO having a new TP seems unnecessarily complex, because I think that servers can simply associate path information to each active connection ID it maintains.

If adding that TP is unnecessarily complex (and I agree that it probably is), what's wrong with recommending servers to remember paths up to as many as the number of spare CIDs that they issue? The whole point of issuing more than one spare CID is that the other endpoint may need to probe additional paths or those probes may be lost, but if you aren't willing to deal with things coming in from 100 places, don't issue 100 CIDs. Obviously that's an exaggeration, but 2/4/6/8 for each client puts a nice bound and is roughly what I'd expect to be sending in a TP anyways.

There's already a mechanism where the person doing the probing can "retire" that CID and signal to you that you no longer need to have that state around, and that's tied directly into their ability to generate new state that you'd need to keep around.

In essence, I think I agree with @martinthomson's statement above, if a server needs to reduce its exposure further it can do so, at the potential cost of performance or burning CIDs faster (as @kazuho points out). 

Enhancing the text around the existing sentence in Section 5.1.1 (that cautions against issuing too many CIDs) to also say that a server needs to maintain this state and should consider that when issuing new CIDs could be reasonable, but I wouldn't consider that time for a new TP?

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