Subject: [tcpm] RACK - Recovery impact on congestion window

From: Felix Weinrank <[email-masked]>
Date: Tue, 29 Jan 2019 18:43:27 +0100

Hallo RACK authors,

I'm currently implementing RACK for SCTP and I've a question regarding 
RACK's impact on the congestion window.

If RACK detects a "normal" loss (no TLP involved), it schedules the lost 
packet for retransmission.
Does this have any impact on the congestion window?

TCP congestion control (rfc5681) will set the cwnd to ssthresh which is 
max(FlightSize / 2, 2*SMSS) in case of a fast retransmission.
Does this also apply for RACK?

Best regards
Felix

---

From: Neal Cardwell <[email-masked]>
Date: Tue, 29 Jan 2019 13:26:11 -0500

> Does this also apply for RACK?

Thanks for your question! Great to hear about your work on RACK for SCTP.

The short version of the answer is that RACK is a loss detection
algorithm, and it considers setting cwnd and ssthresh to be outside
the scope of loss detection and inside the scope of the congestion
control algorithm that is paired with RACK. For that congestion
control algorithm, the RACK draft does not modify the (Reno)
congestion control algorithm [RFC5681] but says senders "SHOULD" use
Proportional Rate Reduction (PRR)  [RFC6937]. That's because PRR has a
good story for cases where large degrees of loss (or small flights of
data) cause the number of packets in flight to be far above or far
below ssthresh.

The "Interaction with congestion control" section of the draft at
https://tools.ietf.org/html/draft-ietf-tcpm-rack attempts to give the
longer version of the answer, including walking through a scenario
similar to the one you describe. Though the scenario below imagines a
TLP, you can imagine the same scenario without the TLP and with the
DUPACK arriving from the original flight of data. Here is an excerpt
of section 7.5 that seems relevant to your question (from
draft-ietf-tcpm-rack-04):

  7.5.  Interaction with congestion control

   RACK intentionally decouples loss detection from congestion control.
   RACK only detects losses; it does not modify the congestion control
   algorithm [RFC5681][RFC6937].  However, RACK may detect losses
   earlier or later than the conventional duplicate ACK threshold
   approach does.  A packet marked lost by RACK SHOULD NOT be
   retransmitted until congestion control deems this appropriate.
   Specifically, Proportional Rate Reduction [RFC6937] SHOULD be used
   when using RACK.
...

   The following simple example compares how RACK and non-RACK loss
   detection interacts with congestion control: suppose a TCP sender has
   a congestion window (cwnd) of 20 packets on a SACK-enabled
   connection.  It sends 10 data packets and all of them are lost.
...

   With RACK, a sender would send the TLP after 2*RTT and get a DUPACK.
   If the sender implements Proportional Rate Reduction [RFC6937] it
   would slow start to retransmit the remaining 9 lost packets since the
   number of packets in flight (0) is lower than the slow start
   threshold (10).  The slow start would again take four round trips (1
   + 2 + 4 + 3 = 10).  The recovery latency would be 2*RTT + 4*RTT, with
   an ending cwnd set to the slow start threshold of 10 packets.

   In both cases, the sender after the recovery would be in congestion
   avoidance.  The difference in recovery latency (RTO + 4*RTT vs 6*RTT)
   can be significant if the RTT is much smaller than the minimum RTO (1
   second in RFC6298) or if the RTT is large.  The former case is common
   in local area networks, data-center networks, or content distribution
   networks with deep deployments.  The latter case is more common in
   developing regions with highly congested and/or high-latency
   networks.  The ending congestion window after recovery also impacts
   subsequent data transfer.

best,
neal

---

From: Felix Weinrank <[email-masked]>
Date: Thu, 31 Jan 2019 13:28:09 +0100

> data) cause the number of packets in flight to be far above or far
Thanks for the explanation.

In case we do not have PRR, or if we want to evaluate the impact of PRR, 
should we consider a loss detected by RACK has the same impact on the CC 
as a loss detected by dup acks?

Best regards
Felix

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 31 Jan 2019 11:52:38 -0800

> as a loss detected by dup acks?
yes I think so.

some more details: RFC5681 TCP Congestion Control Section 4.3

"""
  ... Loss in two successive windows of data, or the loss of a
   retransmission, should be taken as two indications of congestion and,
   therefore, cwnd (and ssthresh) MUST be lowered twice in this case.

   We RECOMMEND that TCP implementors employ some form of advanced loss
   recovery that can cope with multiple losses in a window of data.  The
   algorithms detailed in [RFC3782] and [RFC3517] conform to the general
   principles outlined above.  We note that while these are not the only
   two algorithms that conform to the above general principles these two
   algorithms have been vetted by the community and are currently on the
   Standards Track.
"""

Note that currently only RACK can detect los retransmission - and by
the standard TCP should reduce window again. In reality Linux does not
implement that because that makes the throughput further vulnerable to
burst-induced losses in Cubic or Reno.

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 31 Jan 2019 13:57:17 -0800

> as a loss detected by dup acks?

I guess it will depend on what kinds of traffic pattern (loss, delay,
reorder, BW, etc) you presume.
if RACK and newreno identify the exact same packets as lost, I don't think
there'll be major impacts.
But, as they are different logics this cannot be always true.
--
Yoshi