[tcpm] question regarding draft-gomez-tcpm-delack-suppr-reqs

[Yuchung Cheng <[e-mail]>]

thanks for the talk!

https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-01#section-3.1
"Note that, while Appropriate Byte Counting (ABC) [RFC3465] might be used
   to address this problem, it remains as an experimental mechanism, not
   fully included in RFC 5681, which specifies standard TCP congestion
   control.  "

It's not clear what "fully included" means here. AFAICT, RFC5681
includes the essence of ABC explicitly.

https://tools.ietf.org/html/rfc5681#section-3.1

" During slow start, a TCP increments cwnd by at most SMSS bytes for
   each ACK received that cumulatively acknowledges new data.  Slow
   start ends when cwnd exceeds ssthresh (or, optionally, when it
   reaches it, as noted above) or when congestion is observed.  While
   traditionally TCP implementations have increased cwnd by precisely
   SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND
   that TCP implementations increase cwnd, per:

      cwnd += min (N, SMSS)                      (2)

   where N is the number of previously unacknowledged bytes acknowledged
   in the incoming ACK.  This adjustment is part of Appropriate Byte
   Counting [RFC3465] and provides robustness against misbehaving
   receivers that may attempt to induce a sender to artificially inflate
   cwnd using a mechanism known as "ACK Division" [SCWA99].  ACK
   Division consists of a receiver sending multiple ACKs for a single
   TCP data segment, each acknowledging only a portion of its data.  A
   TCP that increments cwnd by SMSS for each such ACK will
   inappropriately inflate the amount of data injected into the network."

As a side note, Linux stack has implemented the principle of abc in
its congestion control (including slow start)


regarding delayed ACK harming slow-start or latency, I am not too sure either:

1) The ACK is delayed but not the data

2) The delay of the ACK can indeed delay cwnd growth during slowstart.
But the ACK is delayed because the packet is likely a sub-MSS data,
which is again likely caused by application limit (i.e. the
application has sent all its data like a HTTP response). In this case
the delay of the cwnd growth does not hurt the performance since the
application has no data left to send.

   The only penalty occurs when the application has more data to send
but cwnd is still gated by the arrival of the delayed ACK. However, in
many request - response protocol, either the (non-delayed) ACKs
triggered by prior full-MSS data inflight or the delayed ACKs would
have returned to grow the cwnd to sending immediately.

I can construct scenarios where delayed ACK significantly hurts
application. But I don't think the scenario is too common. I will
suggest more tests to quantify the effect of delayed ACK effect on
slow-start.