Re: [tcpm] [EXTERNAL] Re: Last Call: <draft-ietf-tcpm-rack-13.txt>(TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard

[Neal Cardwell <[e-mail]>]

On Thu, Dec 17, 2020 at 2:36 PM Yuchung Cheng <[e-mail]> wrote:

> How about
>
> "9.3.  Interaction with congestion control
>
> RACK-TLP intentionally decouples loss detection ...
> As mentioned in Figure 1 caption, RFC5681 mandates a principle that
> Loss in two successive windows of data, or the loss of a
> retransmission, should be taken as two indications of congestion, and
> therefore reacted separately. However implementation of RFC6675 pipe
> algorithm may not directly account for this newly detected congestion
> events properly. PRR [RFCxxxx] is RECOMMENDED for the specific
> congestion control actions taken upon the losses detected by RACK-TLP"
>
>
> To Makku's request for "what's the justification to enter fast recovery".
> Consider this example w/o RACK-TLP
>
> T0: Send 100 segments but application-limited. All are lost.
> T-2RTT: app writes so another 3 segments are sent. Made to the destination
> and triggered 3 DUPACKs
> T-3RTT: 3 DUPACK arrives. start fast recovery and subsequent cc reactions
> to burst ~50 packets with Reno
>
> In this case any ACK occured before RTO is (generally) considered
> clock-acked, and how I understand Van's initial design.  This behavior
> existed decades before RACK-TLP. RACK-TLP essentially changes the
> "3-segments by app" to "1-segment by tcp".
>

To amplify Yuchung's nice example, and try to restate it in more general
terms:

As far as I'm aware, TLP probes do not introduce materially new congestion
control behaviors, beyond what can happen with [RFC5681] and [RFC6675].

This is because a TLP probe serves much the same probing function that an
application write() could have served, if the application had been so lucky
as to time its write at the appropriate time (i.e. delay the write() of the
last segment in the flight to be 2*SRTT after the preceding segment).

Thus, for any scenario that one constructs where a TLP probe initiates a
fast recovery episode, it is possible to construct, for a TCP
implementation implementing just [RFC5681] and [RFC6675], an application
write() pattern where the on-the-wire behavior is nearly identical to the
TLP-initiated recovery.

For folks concerned about a scenario with FlightSize of 100 segments, and a
sender entering fast recovery and blasting 50 segments, the same behavior
could happen with the existing RFCs [RFC5681] and [RFC6675], which allow
that. And implementers who are worried about such bursts (a very reasonable
thing to be worried about) should probably be implementing pacing and PRR,
or something like that. But that was already true before RACK-TLP.

best,
neal