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

[Markku Kojo <[e-mail]>]

Hi,

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.


1.

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 
articulates?

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.

2.

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

https://www.ee.technion.ac.il/~isaac/p/sigcomm16_vcc_extended.pdf

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

https://mailarchive.ietf.org/arch/msg/tcpm/NU2Hm86s3r5DDd5OsaLmWOTRXPQ/

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.

3.

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 
glitch?

4.

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,

/Markku

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 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis
> Thanks,
> --
> Yoshi
> 
> 
>