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

[Yuchung Cheng <[e-mail]>]

Sorry for the late reply -- forgot to hit send.

On Fri, Oct 28, 2022 at 9:34 PM Markku Kojo
<kojo=[e-mail]> wrote:
>
> 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.

Good catch -- yes the SafeAck was experimented in Google CDN and the
result was reported in a SIGCOMM paper (section 5.2.1) cited in the
draft. But we'd explicitly mention this point in section 3 "Changes
>From RFC 6937"


>
> 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.

I am not aware of further measurements (beside what have been
discussed) about sub-optimal drops. We can add more text on potential
AQM-induced drops in PRR to be comprehensive, as this is indeed what
has been observed.

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

Could you point out where the draft mandates no further rate reductions?

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

The "last resort" retransmission happens when previous (3-dupack)
rules fail to identify further segments' losses as an opportunistic
aggression to retain ack clock. So the 3 dupack rule could be wrong
(or too strict when infight is small). "Good progress" or not is
subjective and depends on how reliable the 3-dupack rule is.

Having said that, I agree that it'll be good to factor in specific
scenarios in SafeACK to slow start. Hence we can add another condition
to SafeACK:
SafeACK MAY be false if the specific loss detection algorithm used
indicates it may not be safe to accelerate and slow start despite
existing conditions listed in the RFC. For example, when RFC 6675
NextSeg() uses the "last resort" retransmission.






>
> 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
> >
> >
> >_______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm