IETF Logo Mail Archive

Re: [quicwg/base-drafts] Persistent congestion threshold is unreliable during the early stages of a connection (#3875)

Kazuho Oku <notifications@github.com> Wed, 15 July 2020 04:02 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2061A3A0E50 for <quic-issues@ietfa.amsl.com>; Tue, 14 Jul 2020 21:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Level:
X-Spam-Status: No, score=-1.483 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_MSPIKE_H2=-0.001, 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 OBZ-XZ03EC7g for <quic-issues@ietfa.amsl.com>; Tue, 14 Jul 2020 21:02:14 -0700 (PDT)
Received: from out-16.smtp.github.com (out-16.smtp.github.com [192.30.254.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D774E3A0E4F for <quic-issues@ietf.org>; Tue, 14 Jul 2020 21:02:14 -0700 (PDT)
Received: from github-lowworker-ca5950c.va3-iad.github.net (github-lowworker-ca5950c.va3-iad.github.net [10.48.17.57]) by smtp.github.com (Postfix) with ESMTP id 359F012110D for <quic-issues@ietf.org>; Tue, 14 Jul 2020 21:02:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1594785734; bh=HkLgxOpmLX3qeX8ettHYFLL/97E+W5jiPJXXqcpchAM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0r6jie3Q8mwfnEr02s7fUVlzTsYI+Bu6ggvtKnCY7renxe9aAFb1tOHdIuAO106qg v1G9c04bhhWpeynRTs0cWC+M4xvTtPUQbxfbR9nf/QJXYTF+V1VmQHal9dcsXvUppF 2LS+pPpC2SQEitdv04qEOpasUQsdbuZYQDisnXQw=
Date: Tue, 14 Jul 2020 21:02:13 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4XYMJQ4AHZ4JYTDTF5DJQMLEVBNHHCN3XFKQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3875/658532149@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3875@github.com>
References: <quicwg/base-drafts/issues/3875@github.com>
Subject: Re: [quicwg/base-drafts] Persistent congestion threshold is unreliable during the early stages of a connection (#3875)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f0e7fc5e173a_7e053fd12d0cd9688524b1"; 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/5pwtKPvwvU49Lb9a7eDMfR3EOQs>
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: Wed, 15 Jul 2020 04:02:16 -0000

@janaiyengar Thank you for summarizing the issue.

Yes, my point was that the current definition of persistent congestion is inaccurate *if* it based on the rationale that the endpoint would have had occasions to send 3 probe packets, because the endpoint might have had a larger RTT estimate before receiving the ACK that triggers the persistent congestion check.

That said, in the current computation, we do have the guarantee that the endpoint would have sent at least 2 probe packets, because PTO never decreases by more than 25% when obtaining just one RTT sample. If we think that is enough, I'm fine with going with what we have now in #3889.

-- 
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/3875#issuecomment-658532149

v2.28.0 | Report a Bug | By Email | System Status