Re: [quicwg/base-drafts] Rework section on persistent congestion (#3961)

mjoras <notifications@github.com> Wed, 29 July 2020 00:59 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 8FEF03A0DCE for <quic-issues@ietfa.amsl.com>; Tue, 28 Jul 2020 17:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.716
X-Spam-Level:
X-Spam-Status: No, score=-1.716 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_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cA4orH9lHdDe for <quic-issues@ietfa.amsl.com>; Tue, 28 Jul 2020 17:59:26 -0700 (PDT)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE43E3A0DCD for <quic-issues@ietf.org>; Tue, 28 Jul 2020 17:59:22 -0700 (PDT)
Received: from github-lowworker-a6a2749.va3-iad.github.net (github-lowworker-a6a2749.va3-iad.github.net [10.48.16.62]) by smtp.github.com (Postfix) with ESMTP id A4BFA902644 for <quic-issues@ietf.org>; Tue, 28 Jul 2020 17:59:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1595984361; bh=IFkZvhYs/PPhmSJ3DkK65YY6yNQs94+mQVejAIKbt9w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iT/WAE5XpOaYv9S8oid0HaB6rk0QO5maUHmC/W0xGCLsTzSsrW2BdZomxpC96pU8C yhH5YrSnqe+bZG0kJ1gpWW8pMpwLxuoU78na1lDw+qqej3HwRrHcvhpHpAvlhHp+ez +EwF++u2D/gIWLz1czkkJePgqMmqg3iadK4H4EiM=
Date: Tue, 28 Jul 2020 17:59:21 -0700
From: mjoras <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZDODACJUSMMHWO7WV5FSVOTEVBNHHCPPLSJE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3961/review/457125466@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3961@github.com>
References: <quicwg/base-drafts/pull/3961@github.com>
Subject: Re: [quicwg/base-drafts] Rework section on persistent congestion (#3961)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f20c9e993adf_13d016f88679b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mjoras
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/hYuQed90cQuj8awkZ20Z0wNsBl0>
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, 29 Jul 2020 00:59:28 -0000

@mjoras commented on this pull request.



>  max_ack_delay irrespective of the packet number spaces in which losses are
 established.
 
+This duration is intended to allow a sender to use initial PTOs for aggressive
+probing, as TCP does with Tail Loss Probe (TLP; see {{RACK}}), before
+establishing persistent congestion, as TCP does with a Retransmission Timeout
+(RTO; see {{?RFC5681}}).
+
+The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is
+approximately equivalent to two TLPs before an RTO in TCP.
+
+This design uses an explicit duration instead of consecutive PTO events since
+the PTO timer is restarted every time an ack-eliciting packet is sent. An
+application that trickles data restarts the PTO timer repeatedly, preventing the

Yeah I think this paragraph is a little confusing. I think the intent is basically suggesting that an application which itself is steadily writing relatively small amounts of data into the transport will perpetuate the PTO timer, and hence detecting persistent congestion should not depend on this. However the use of "application" and "trickle" together is probably going to be confusing to some.

Additionally it seems like the first sentence and the last sort of overlap, which makes the paragraph read a little strangely.

-- 
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/pull/3961#discussion_r461976858