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

Kazuho Oku <notifications@github.com> Mon, 02 March 2020 13:45 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 843853A0C13 for <quic-issues@ietfa.amsl.com>; Mon, 2 Mar 2020 05:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Status: No, score=-3.099 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ydDegdrmq0SF for <quic-issues@ietfa.amsl.com>; Mon, 2 Mar 2020 05:45:09 -0800 (PST)
Received: from out-1.smtp.github.com (out-1.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC763A0C10 for <quic-issues@ietf.org>; Mon, 2 Mar 2020 05:45:09 -0800 (PST)
Date: Mon, 02 Mar 2020 05:45:09 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1583156709; bh=1+XLoPFhlmgM/0AO+4A4wQa8FXbvMQQSgxF8aXYY8Ic=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=lxSVdF0IcWzeAzYPN12APBRyaAkPzZ0QpqKelt5XEltxJ2W2uQxmTYbLAW3wFIpX2 uDuwGMSxpghDUjGBsKq0eRz6WaAdRDgA4U8hrUCptxe40Rj2ItBgAByY0ouCOxiYXK qutSguXues/BiO/9YHXdhfOkhHQy+NIbqbFxfHRw=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4OQB2US5PSEAWLCYN4NDXOLEVBNHHCENSPWY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3489@github.com>
Subject: [quicwg/base-drafts] How many probed paths should a server remember? (#3489)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e5d0de5474e_42233fceb02cd96825323c"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/e6ZBXxp0gC0iOL2o31NaKcKupbw>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 13:45:12 -0000

At the moment, it is my understanding that we do not give any advice in particular. But to me it seems that there would be issues if the number of probed paths that the server remembers is less than the number of spare connection IDs it issues.

Consider the case of a server that advertises three spare connection IDs, but retains information of one probing path (i.e. remember one set of 5-tuple that has been probed, and the connection ID being associated to that tuple).

If a client connecting to this server probes three paths concurrently, and if it keeps on sending PATH_CHALLENGE packets periodically on that path (in order to keep the holes in NAT open), two issues arise:
* The connection ID pool of the server would run out quickly, as the server would use a new connection ID for each probing packet it sends in response (because each probing packet sent by the client would have a different source address than the previous packet). This is an issue, as we state that _an endpoint MAY limit the frequency or the total number of connection IDs issued for each connection to avoid the risk of running out of connection IDs_ [section 5.1.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-5.1.1-5).
* The purpose of path probing is to prepare an alternate path beforehand. That benefit diminishes if the server remembers only one (or few) of the paths being probed.

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.

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