On Thu, Dec 17, 2020 at 2:36 PM Yuchung Cheng <ycheng@xxxxxxxxxx> 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 specificcongestion 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-TLPT0: 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 DUPACKsT-3RTT: 3 DUPACK arrives. start fast recovery and subsequent cc reactions to burst ~50 packets with RenoIn 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.
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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
