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

Martin Thomson <notifications@github.com> Tue, 28 July 2020 03:49 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 99BA53A0BB6 for <quic-issues@ietfa.amsl.com>; Mon, 27 Jul 2020 20:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
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: 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 oYSEYYFpRY9K for <quic-issues@ietfa.amsl.com>; Mon, 27 Jul 2020 20:49:46 -0700 (PDT)
Received: from out-25.smtp.github.com (out-25.smtp.github.com [192.30.252.208]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEBA3A0BC7 for <quic-issues@ietf.org>; Mon, 27 Jul 2020 20:49:40 -0700 (PDT)
Received: from github-lowworker-0f7e7fd.ash1-iad.github.net (github-lowworker-0f7e7fd.ash1-iad.github.net [10.56.110.17]) by smtp.github.com (Postfix) with ESMTP id 10CFB840EA0 for <quic-issues@ietf.org>; Mon, 27 Jul 2020 20:49:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1595908179; bh=JULKyKqTDdeT7JY+49x+iBANyM6CkWWfwaEZF6n4+78=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=cDR6wgleKuS9cuYBQ74ApbpQoxiHLi6Nhkc/T3yUzYSba/YDxIGmsH1Jp2Lr3z0dS fEiwleN0kcGl3/oHmsVlU4KdR6cdbEtFDARzMaiCkTzu2qeSjC/u/RHD8HCfn5UzHu AMZRDTVuV0RZX+LYVcVPBU7gkSvFzpjmZFPf9Oso=
Date: Mon, 27 Jul 2020 20:49:39 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4V3LB3QISRWBFQS6F5FOAVFEVBNHHCPPLSJE@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/456280522@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_5f1fa05310e9_31e73fcff56cd96426094f"; 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: <https://mailarchive.ietf.org/arch/msg/quic-issues/Dqci0OnIC_auquEOEo_zvyVBmgI>
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: Tue, 28 Jul 2020 03:49:49 -0000

@martinthomson commented on this pull request.

This is much clearer, thanks.

> -sent over a long enough period of time, the network is considered to be
-experiencing persistent congestion.  Commonly, this can be established by
-consecutive PTOs, but since the PTO timer is reset when a new ack-eliciting
-packet is sent, an explicit duration must be used to account for those cases
-where PTOs do not occur or are substantially delayed. The rationale for this
-threshold is to enable 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 duration is computed as follows:
+When a sender establishes loss of all in-flight packets sent over a long enough
+duration, the network is considered to be experiencing persistent congestion.
+
+### Duration {#duration}

```suggestion
### Duration {#pc-duration}
```

>  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

What is an "initial PTO"?  I think that you want to rephrase this.

Is the intent not to give the sender an opportunity to send multiple times before declaring PC?  And that we want to allow for more than one probe packet to be sent so that transient loss does not cause PC unnecessarily.

> +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
+PTO timer from expiring for a potentially long period of time. A consequence of
+this design is that persistent congestion can be established without the
+occurrence of any PTOs.
+
+### Declaring Persistent Congestion
+
+A sender declares persistent congestion on receiving an acknowledgement, if the
+following conditions are true:
+
+* there are at least two ack-eliciting packets that are declared lost;
+
+* the duration between the send times of these two packets exceeds the
+  persistent congestion duration ({{duration}}); and

```suggestion
  persistent congestion duration ({{pc-duration}}); and
```

> +* the duration between the send times of these two packets exceeds the
+  persistent congestion duration ({{duration}}); and
+
+* all packets sent between those times are declared lost.
+
+Since network congestion is not affected by packet number spaces, persistent
+congestion SHOULD be established across packet number spaces. A sender that does
+not have state for all packet number spaces or an implementation that cannot
+compare send times across packet number spaces MAY use state for just the packet
+number space that was acknowledged.
+
+When persistent congestion is declared, the sender's congestion window MUST be
+reduced to the minimum congestion window (kMinimumWindow).  This response of
+collapsing the congestion window on persistent congestion is functionally
+similar to a sender's response on a Retransmission Timeout (RTO) in TCP
+({{RFC5681}}) after Tail Loss Probes (TLP; see {{RACK}}).

The repetition of the RTO and TLP citations seems a little duplicative here.

```suggestion
({{RFC5681}}) after Tail Loss Probes ({{RACK}}).
```

-- 
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#pullrequestreview-456280522