[tcpm] clarifying applicability of PRR: draft-ietf-tcpm-prr-rfc6937bis-12.txt

Neal Cardwell <ncardwell@google.com> Sun, 28 July 2024 17:44 UTC

Return-Path: <ncardwell@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0862C15108A for <tcpm@ietfa.amsl.com>; Sun, 28 Jul 2024 10:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.606
X-Spam-Level:
X-Spam-Status: No, score=-17.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLoHBJ5mdZpJ for <tcpm@ietfa.amsl.com>; Sun, 28 Jul 2024 10:44:28 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08B9C151091 for <tcpm@ietf.org>; Sun, 28 Jul 2024 10:44:28 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id ca18e2360f4ac-81f8f0197abso100723339f.2 for <tcpm@ietf.org>; Sun, 28 Jul 2024 10:44:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722188667; x=1722793467; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OiwYLtqVHBFvWoHNQKTbPO6oWmUMXAX4MT7KKvjsNYQ=; b=Ja/VHm+S4PMPyfLK9p/GWCmhtJJYI5SHYZJ4u14LUfGTRFrXhkW/0yQH4NJzpgbRrd +m59tstKDwoDaIEkbgr/QqSf/RsP+lySCfPGnwJ2zz7Ol+bUtiNqVbAgzsm1JnTGGAho 1bPWoBwvc5RG7tqDiIiU+Z34f9wcWSqmdpcD7p6qcTSGu0pdWVPHRXiw0eAMRUJ/wq7A VcBAuCzHfgf41ubSTkYDc/1ccSzGFrHm7XF5cdc0WS8lTJJH6zIc0CN7pyDU5HYJ0Kh7 r3Zsaoo6cnLQyhk4ATQqkuUuoPHtAyHx36v5vlU6AlWpXBCZE24dRjasfDu1WnbKS3e9 lsyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722188667; x=1722793467; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OiwYLtqVHBFvWoHNQKTbPO6oWmUMXAX4MT7KKvjsNYQ=; b=WCuPwPKNU+1d4azbyHEtSCZxd1S2hJMNYMSuIXmU1qUfGBaLIRAqQt8sXWeA981Sau KINsibXV5a3OdcuzVsT5edPPBmKsOqE1kmC5vrYFyQVH9cTl9F0bS6xWImYConK7PmRv r5ooUswHT0XZsOVfwlS6VEmur/6HAsJUeIYdV395Me+jNg8HYTa1p9Zk+VsOv1A8i8ZE a5HdfaEOT8bbl5KR5KKNEugiXdDgusAudHubILNbCvMII0pkBaMieVv1wX1Tm4df7QCV Js1FJ3c5C034IuF8imPqcubbRiu2MJFN93QiI15co47gyKdTuWXVNNsNvHRcWjpRt1c8 mEEw==
X-Gm-Message-State: AOJu0Yy/3CCRq9e3x+b3L02PdqvjAK3fZCYHYi83FMtTVxYzgzPkmktv Ad5+Hs52ETYFNzDJ4rGcvCISwNijVuwZJtyjnhDdA2IVdQHMqGlDIEdYPaZy8mFmVVSqpuXJRXS SPCeYe4WIoPaTZ4Nk4urbcMTl9RPmBiaIn4oIhPUXnHK//TiZkLAa
X-Google-Smtp-Source: AGHT+IHigRT4lojSO3dyZ1KiFh/FuMo2wJEWHhjevcRTzaSrmij+Rz0uNI/vJeDP7cvmI4kCNOQ6l0v7k4u5ukbWozE=
X-Received: by 2002:a05:6e02:12e2:b0:397:c5da:dc02 with SMTP id e9e14a558f8ab-39aec2cd974mr81328855ab.4.1722188667171; Sun, 28 Jul 2024 10:44:27 -0700 (PDT)
MIME-Version: 1.0
References: <172218814972.1543605.825241079771272474@dt-datatracker-659f84ff76-9wqgv>
In-Reply-To: <172218814972.1543605.825241079771272474@dt-datatracker-659f84ff76-9wqgv>
From: Neal Cardwell <ncardwell@google.com>
Date: Sun, 28 Jul 2024 13:44:07 -0400
Message-ID: <CADVnQyk5O3-nLzmZRMrXfw1hzzXk0DznmYPdWsvfSbEZE8poJA@mail.gmail.com>
To: tcpm <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000beb259061e524b43"
Message-ID-Hash: MSIUL3OQIVH2IPWXUPVTBZIRWBIZSLO6
X-Message-ID-Hash: MSIUL3OQIVH2IPWXUPVTBZIRWBIZSLO6
X-MailFrom: ncardwell@google.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tcpm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: i-d-announce@ietf.org, Matt Mathis <ietf@mattmathis.net>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tcpm] clarifying applicability of PRR: draft-ietf-tcpm-prr-rfc6937bis-12.txt
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/HNdSbFgZwuEDYLtP95DUPz53ffU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Owner: <mailto:tcpm-owner@ietf.org>
List-Post: <mailto:tcpm@ietf.org>
List-Subscribe: <mailto:tcpm-join@ietf.org>
List-Unsubscribe: <mailto:tcpm-leave@ietf.org>

Based on suggestions in the TCPM session this week, we have posted updates
today to the PRR draft to try to clarify the breadth of the class of
congestion algorithms for which it is applicable.

Full diff:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-tcpm-prr-rfc6937bis-10&url2=draft-ietf-tcpm-prr-rfc6937bis-12&difftype=--html

The main changes are in the following sections/paragraphs; here is the new
draft text:

2.
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-12#section-2>
Background
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-12#name-background>

Congestion control algorithms like Reno [RFC5681
<https://www.rfc-editor.org/info/rfc5681>] and CUBIC [RFC9438
<https://www.rfc-editor.org/info/rfc9438>] require that TCP (and other
protocols) reduce their congestion window (cwnd) in response to losses.
Fast recovery is the reference algorithm for making this adjustment using
feedback from acknowledgements. Its stated goal is to recover TCP's self
clock by relying on returning ACKs during recovery to clock more data into
the network. Without PRR, fast recovery typically adjusts the window by
waiting for a large fraction of a round-trip time (one half round-trip time
of ACKs for Reno [RFC5681 <https://www.rfc-editor.org/info/rfc5681>], or
30% of a round-trip time for CUBIC [RFC9438
<https://www.rfc-editor.org/info/rfc9438>]) to pass before sending any data.
¶
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-12#section-2-1>

...
4.
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-12#section-4>Relationships
to other standards
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-12#name-relationships-to-other-stan>

PRR MAY be used in conjunction with any congestion control algorithm that
intends to make a multiplicative decrease in its sending rate over
approximately the time scale of one round trip time, as long as the current
volume of in-flight data is limited by a congestion window (cwnd) and the
target volume of in-flight data during that reduction is a fixed value
given by ssthresh. In particular, PRR is applicable to both Reno [RFC5681
<https://www.rfc-editor.org/info/rfc5681>] and CUBIC [RFC9438
<https://www.rfc-editor.org/info/rfc9438>] congestion control. PRR is
described as a modification to "A Conservative Loss Recovery Algorithm
Based on Selective Acknowledgment (SACK) for TCP" [RFC6675
<https://www.rfc-editor.org/info/rfc6675>]. It is most accurate with SACK [
RFC2018 <https://www.rfc-editor.org/info/rfc2018>] but does not require
SACK.

...¶
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-12#section-4-1>

Best regards,
neal


On Sun, Jul 28, 2024 at 1:36 PM <internet-drafts@ietf.org> wrote:

> Internet-Draft draft-ietf-tcpm-prr-rfc6937bis-12.txt is now available. It
> is a
> work item of the TCP Maintenance and Minor Extensions (TCPM) WG of the
> IETF.
>
>    Title:   Proportional Rate Reduction for TCP
>    Authors: Matt Mathis
>             Nandita Dukkipati
>             Yuchung Cheng
>             Neal Cardwell
>    Name:    draft-ietf-tcpm-prr-rfc6937bis-12.txt
>    Pages:   20
>    Dates:   2024-07-28
>
> Abstract:
>
>    This document updates the experimental Proportional Rate Reduction
>    (PRR) algorithm, described RFC 6937, to standards track.  PRR
>    provides logic to regulate the amount of data sent by TCP or other
>    transport protocols during fast recovery.  PRR accurately regulates
>    the actual flight size through recovery such that at the end of
>    recovery it will be as close as possible to the slow start threshold
>    (ssthresh), as determined by the congestion control algorithm.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-prr-rfc6937bis/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tcpm-prr-rfc6937bis-12.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-prr-rfc6937bis-12
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> tcpm mailing list -- tcpm@ietf.org
> To unsubscribe send an email to tcpm-leave@ietf.org
>