[tsvwg] some feedback on draft-ietf-tsvwg-careful-resume-12

[Neal Cardwell <[e-mail]>]

Hi,

Here's some feedback on a partial reading of
draft-ietf-tsvwg-careful-resume-12, "Convergence of Congestion Control from
Retained State".

Sorry for the delayed feedback. A long 3-day weekend in the US gave me some
extra time. :-)

My main concern was the handling of application-limited behavior in the
"Unvalidated Phase"; AFAICT this handling is buggy (see below for
details)...

Notes:

---

Re: "It introduces an alternative mechanism to select initial CC
parameters, that seek", this seems to have a typo. Perhaps consider: "It
introduces an alternative mechanism to select initial CC parameters that
seeks"

---
Re: "Successful validation can further increase the CWND, resulting in a
CWND after validating that the used rate did not result in congestion."

What does "resulting in a CWND" mean? This reads as if there is a typo that
accidentally omitted some words?

Consider perhaps:

"Successful validation can allow further increases of the CWND; after
validating that the used rate did not result in congestion, the sender can
quickly increase CWND to saved_cwnd."

---
Re: "Suppose, for example a connection using the classic TCP congestion
control. In "slow start" mode, a Reno congestion control would normally
converge on a "slow start threshold" set to half the volume of data in
flight"

The term "classic" is sometimes used to refer to both Reno and CUBIC, and
"converge" in this context IMHO is a little confusing/misleading.

Consider perhaps: "Suppose, for example a connection using Reno TCP
congestion control. When exiting "slow start" mode due to loss, Reno would
normally set CWND to a "slow start threshold" set to half the volume of
data in flight"

---

Figure 1 includes a state labelled "Observing (Normal)" and a second state
labelled "Normal". It was unclear to me, upon first reading the figure,
whether these were supposed to represent the same state.

---
In, "3.2. Reconnaissance Phase",

re: "Reconnaissance Phase (Confirming the RTT): During this phase, a sender
MUST record the minimum RTT for the current connection as the current_rtt.
... When a path is not confirmed, Careful Resume is not used and the sender
enters the Normal Phase with a CWND that was not modified by Careful
Resume."

That text makes it sound like "Confirming the RTT" consists merely of
recording the minimum RTT for the current connection as the current_rtt.
But "4.2.1. Confirming the Path" describes a more sensible approach of
comparing current_rtt with saved_RTT.

Instead of  "Reconnaissance Phase (Confirming the RTT): During this phase,
a sender MUST record the minimum RTT for the current connection as the
current_rtt." I would suggest something more like: "Reconnaissance Phase
(Recording the current_rtt): During this phase, a sender MUST record the
minimum RTT for the current connection as the current_rtt."

---

In, "3.2. Reconnaissance Phase", re: "When a sender has confirmed the RTT",
I would suggest a forward reference to what it means to "confirm the RTT",
like: "When a sender has confirmed the path (see section 4.2.1. 'Confirming
the Path')".

---
In, "3.2. Reconnaissance Phase", re: "When a sender has confirmed the RTT
and also has received an acknowledgement for the initial data without
reported congestion, it MAY then enter the Unvalidated Phase. This
transition occurs when more data is sent than normally permitted by the
congestion control algorithm."

This seems contradictory, AFAICT.

The first sentence seems to say you "MAY" enter the "Unvalidated" phase
without sending "more data is sent than normally permitted by the
congestion control algorithm": "When a sender has confirmed the RTT and
also has received an acknowledgement for the initial data without reported
congestion, it MAY then enter the Unvalidated Phase."

The second sentence seems to contradict that: "This transition occurs when
more data is sent than normally permitted by the congestion control
algorithm.".

---

In section "3.3. Unvalidated Phase", Re: "If the current_rtt is greater
than or equal to (saved_rtt / 2) or the current_rtt is less than or equal
to (saved_rtt x 10) (see Section 4.2.1), the sender MUST enter the Normal
Phase"... it seems like there are typos there that invert the sense of the
semantics. If current_rtt is exactly equal to saved_rtt, it will fail those
checks and force an entry of "Normal Phase". AFAICT the intended text was
something like: "If the current_rtt is *less* than or equal to (saved_rtt /
2) or the current_rtt is *greater than* (saved_rtt x 10) (see Section
4.2.1), the sender MUST enter the Normal Phase".

---

In section "3.3. Unvalidated Phase", Re: "The calculation of a sending rate
from a saved_cwnd is directly impacted by the RTT, therefore a significant
change in the RTT is a strong indication that the previously observed CC
parameters are not be valid for the current path."

There's a typo in the phrase: "are not be valid".

More importantly: even if the CC is something like BBR, with a separate
saved max_bw that can prevent changes in RTT from distorting the sending
rate, I would argue that this kind of significant change in the RTT is a
signal that likely the current path conditions (often the bottleneck radio
link conditions or bottleneck cross-traffic) are very different from the
conditions at the time the saved_cwnd or other parameters were saved, and
so the flow should not reuse the saved CC parameters.

Consider perhaps something like: "This kind of significant change in the
RTT is a signal that likely the current path conditions (e.g., the route,
or bottleneck radio link conditions, or bottleneck cross-traffic) are
significantly different from the conditions at the time the CC parameters
were saved, and so the flow should not reuse the saved CC parameters.
Furthermore, for window-based CCs, the calculation of a sending rate from a
saved_cwnd is directly impacted by the RTT, so large changes in RTT may
produce unsafe changes in sending rates."

---

In section "3.3. Unvalidated Phase", Re: "Unvalidated Phase (Completed
sending all unvalidated packets): The sender enters the Validating Phase
when the flight_size equals the CWND."

This seems to specify unsafe behavior for connections that are
application-limited in the "Unvalidated Phase". Suppose a connection is
application-limited in the "Unvalidated Phase". It may increase CWND to a
large jump_cwnd of, say 100,000 packets. But because the flow is
application-limited, its flight_size may only reach 99,999 packets. That's
a very large flight of data, far beyond the defaults for any CC I know of,
so ideally after sending the 99,999 packets, the flow should enter the
"Validating Phase", so that it can check "whether all packets sent in the
Unvalidated Phase were received without inducing congestion", and enter
Safe Retreat if needed.  Instead, because flight_size is always less than
CWND, the algorithm has the flow stay in  the "Unvalidated Phase" forever,
increasing PipeSize beyond any quantity that corresponds to anything
happening in the system, and never validating the impact of its massive
cwnd. :-)

---

In section "3.4. Validating Phase", Re: "The Validating Phase checks
whether all packets sent in the Unvalidated Phase were received without
inducing congestion." The term "all" seems like a strong claim. Unless
there is reordering, the flow will only have access to ACKs from the last
round trip of the  Unvalidated Phase, not "all packets sent in the
Unvalidated Phase".

---

In section "3.4. Validating Phase", Re: "When using BBR Section 4.5,
validation is performed using the regular BBR rules for exiting Startup.
The measured delivery rate will reflect the actual capacity of the
network." The measured delivery rate will typically not reflect the actual
capacity of the network if the flow is application-limited. And the
measured delivery rate reflects the flow's share of the capacity of the
bottleneck link, not the full capacity of the network. And "capacity" is
ambiguous, since it can refer to volumetric capacity (number of packets
that will fit in the path without loss) or bandwidth capacity (the rate at
which the path can forward packets). So I'd suggest rephrasing this as
something like: "When using BBR (see Section 4.5), validation is performed
using the regular BBR rules for exiting Startup. Upon exiting Startup, the
connection estimates that the measured delivery rate will reflect the
flow's share of the actual bottleneck bandwidth."

---

In section "A.2. Example with No Loss, Rate-Limited", Re: "the sender will
still not have fully-used the CWND. It then enters the Validating Phase".
This passage seems to contradict section "3.3. Unvalidated Phase", which
says: "The sender enters the Validating Phase when the flight_size equals
the CWND."

---

best regards,
neal