[tcpm] Review of draft-fairhurst-tcpm-newcwv-03

[Yuchung Cheng <[e-mail]>]

Summary:

First of all the problem this draft is trying to solve is important:
AFAIK servers and data-centers disable slow-start after idle because
it simply hurts latency too badly. Modern TCP-smart applications all
use persistent connections to amortize handshake and slow-start
overhead and the RFC2861 standard nullifies that to certain extent.
While the applications don't want to create big burst to cause
congestion, they have no better choices (low latency vs occasional
burst losses: choose one). This draft proposes a middle road. Thanks
for starting this!

Details:
Section 1
I found the term "variable-rate" application little awkward: for
example some constant-rate (CBR) app may still go through slow-start,
overshoots, and experiences non-validated phases. But it's nit.

Section 4.1
Since the draft already requires SACK, I recommend to use RFC3517 pipe
to better measure the amount of outstanding data in the network.

Section 4.2

a) Justification of 2/3 and 1/3 is much appreciated.
b) During the validated phase when FS >= 2/3cwnd, are ACKs used to
compute new cwnd. E.g., in slow-start with cwnd=30 and FS=20, will the
next 10 ACKs increase the cwnd to 40? also is this phase check applied
to both transmitting new data and receiving acks?


Section 4.3.1
"  An application that remains in the non-validated phase for a period
   greater than five minutes is required to adjust its congestion
   control state.  At the end of the non-validated phase, the sender
   MUST update cwnd:

           cwnd = max(FlightSize*2, IW)."
Some justification to set cwnd to double the FlightSize? it seems with
2/3 rule in the non-validated phase, cwnd can grow to as big as 4/3 of
original value at the end of the non-validated phase.

btw, it flows better if 4.3.1 and 4.3.2 are swapped.

Section 4.3.2
"A sender that detects a packet-drop or receives an ECN marked packet
 MUST calculate a safe cwnd, based on the volume of acknowledged data:

        cwnd = FlightSize - R.

 Where, R is the volume of data that was reported as unacknowledged by
 the SACK information.  This follows the method proposed for Jump
 Start [[Liu07]."
so is R 0 or 1 of of an ECN marked packet?

Some justification to your approach compared to RFC5861?
i.e. why (FlightSize - R)/2 vs FlightSize/2?


After thougths:
Since this RFC attempts to replace RFC2861, maybe it can also address
this performance handicap in the introduction of RFC2861?

"We propose that the TCP sender should not increase the congestion window
   when the TCP sender has been application-limited (and therefore has
   not fully used the current congestion window).  We have explored
   these algorithms both with simulations and with experiments from an
   implementation in FreeBSD."

This happens frequently today because many application pauses are
within RTOs. For example, the acks of smaller HTTP responses after
some big one will now not used to compute cwnd. They are used for RTO
estimation only.

I think we need a general solution to cover when cwnd > pipe. So far
we have laminar and your draft. But a unified solution would be great
but we are making progress :)

Thanks.