Re: [tcpm] WGLC for draft-ietf-tcpm-prr-rfc6937bis

Markku Kojo <> Sat, 29 October 2022 04:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB69AC14F736 for <>; Fri, 28 Oct 2022 21:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0sImuNRy7CFM for <>; Fri, 28 Oct 2022 21:34:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 959C5C14F727 for <>; Fri, 28 Oct 2022 21:34:00 -0700 (PDT)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 Sat, 29 Oct 2022 07:33:49 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=date:from:to:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=skBOuc PRGXHEnSGT+KfNPiynfXHXbDNqrFfCqdcGB08=; b=Tdrz3Pe3JTPOLSsQwvZyHi XfUwrXh0Z8fy7s0LarpchFkxKxbAtBF1KYQWboEa+LCcNXfUdkuzUa06TtllxJ7G rxr84Ctgc0nqGll9yDCxh2rEkUyOQJZFhXq80GCzcU6WuOEHYqftdOyYimndEAD5 WTeDY0HYha7KM2pbT9BzQ=
Received: from hp8x-60 ( []) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by with ESMTPSA; Sat, 29 Oct 2022 07:33:49 +0300 id 00000000005A00CF.00000000635CAD2D.00005351
Date: Sat, 29 Oct 2022 07:33:47 +0300
From: Markku Kojo <>
To: " Extensions" <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_script-21351-1667018029-0001-2"
Content-ID: <>
Archived-At: <>
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-prr-rfc6937bis
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Oct 2022 04:34:08 -0000


I've reviewed the draft. I think it is good to have this doc published 
and that the draft is in pretty good shape.  However, I have a few 
questions and proposals.


Given that RFC6937 is Experimental with some measurement results using 
the algos of RFC6937 and this draft proposes some changes like the 
"safeACK" heuristic that seem to make good sense I wonder if there are 
any experimental results to back up the positive outcomes that the draft 

I'm asking because the draft kinda indicates that this has not been 
explored but at the same time the text describes the benefits in a 
similar fashion that one expects to read when there is measurement data 
showing the benefits. This is a bit confusing.


The draft explains how Strong Packet Conservation Bound follows the 
spirit of Van Jacobson's packet conservation principle and that in a 
simple network environment with a tail drop queue  PRR would 
not cause any additional drops. This is all correct for a tail-drop 
setting envisioned in the Appendix A and I agree with the text.

However, if the bottleneck queue employs AQM, packet dynamics and 
behaviour tends to be different. With (almost) any AQM the dropping 
behaviour changes such that once the queue delay/length has been above a 
threshold (e.g., target in CoDel, MinTh in RED) for a long enough time 
(e.g., interval in CoDel) the AQM enters its main operating region and 
starts dropping packets, continuing dropping until the queue delay/length 
is again below the target.

With a non-PRR sender cwnd is reduced immediately when FR&FR is entered 
and the sender does not inject more packets for  while, allowing the 
AQM queue to drain below the target (in most cases). However, with a PRR 
sender the sending rate is not reduced immediately and the queue is not 
allowed to drain similarly. This means that the new data packets (and 
additional retransmissions) that are sent after the fast retransmit are 
subject to drops because the AQM is still in its main operating region.

This behavior has been shown in paper

that Michael pointed out some while ago when he questioned the douple 
drops he had seen:

So, I am wondering if any additional measurements exists with PRR over an 
AQM botttleneck. Anyway, IMO this shortcoming should be discussed in the 
draft because it may result in suboptimal behaviour with a PRR sender 
over an AQM bottleneck.


Given that PRR is recommended to be used with RACK-TLP, it seems that the 
algo does not address the case where RACK-TLP detects a lost 
retransmission, requiring another rate reduction. Now it seems that 
RACK-TLP/PRR may continue with no further rate reductions all the way 
until all losses in a window of data have been recovered no matter how 
many times a retransmission (or some retransmissions) have been dropped 
during the fast recovery. Shouldn't this be addressed as a serious 


It might be useful to specify more precisely the interpretation of
safeACK when used with RFC 6675 "last resort" retransmissions specified 
in Sec 4, NextSeg () steps (3) and (4). Isn't it possible that an 
arriving Ack does not indicate new losses but a "last resort" 
retransmission would be needed? In such a case the recovery is not 
necessarily making "good progress"?

Best regards,


On Wed, 12 Oct 2022, Yoshifumi Nishida wrote:

> Hi folks,
> This e-mail announces that we initiate a WGLC for draft-ietf-tcpm-prr-rfc6937bis
> Please send your feedback to the ML.
> The WGLC runs untils Oct 28.
> The URL for the doc is
> Thanks,
> --
> Yoshi