From nobody Wed Mar 11 22:45:16 2020 Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454803A0F8F for ; Wed, 11 Mar 2020 22:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzqqTaBCH45W for ; Wed, 11 Mar 2020 22:45:13 -0700 (PDT) Received: from out-13.smtp.github.com (out-13.smtp.github.com [192.30.254.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D57F3A0F86 for ; Wed, 11 Mar 2020 22:45:13 -0700 (PDT) Received: from github-lowworker-3a0df0f.ac4-iad.github.net (github-lowworker-3a0df0f.ac4-iad.github.net [10.52.25.92]) by smtp.github.com (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; d=github.com; 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: In-Reply-To: References: 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 X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org 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 ----==_mimepart_5e69cc6837ab2_31893f80466cd9681705dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: https://github.com/quicwg/base-drafts/issues/3489#issuecomment-598017306 ----==_mimepart_5e69cc6837ab2_31893f80466cd9681705dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

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, view it on GitHub, or unsubscribe.

----==_mimepart_5e69cc6837ab2_31893f80466cd9681705dc--