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

Dear Yuchung,

Thanks for your questions and comments.

Please find below my inline responses:

> 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."

Note that the problem pointed out is that, as stated in the RFC 5681 text
above:

   "During slow start, a TCP increments cwnd by at most SMSS bytes for
    each ACK received that cumulatively acknowledges new data"

It may be desirable to support, during slow start, a cwnd increase by more
than SMSS per each ACK acknowledging new data.

In fact, couple of paragraphs later, RFC 5681 explicitly indicates the
following:

   "We note that [RFC3465] allows for cwnd increases of more than SMSS
   bytes for incoming acknowledgments during slow start on an
   experimental basis; however, such behavior is not allowed as part of
   the standard."

That is what we meant by "not fully included in RFC 5681" in our document.

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

Thanks for the information.

Yes, in fact, I second the WG members who stated on the chat, during the
interim, that it is surprising that ABC remains as an experimental
document.

I realize that, at an implementation level, the problem pointed out above
is being addressed in many platforms.

> 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.

Yes, I tend to agree.

In fact, the two main problems due to Delayed ACKs that we identified so
far in the area of slow start are:

- The fact that ABC might not always be supported (due to its
"Experimental" status).

- Precluding sender behaviors such as chirping.

Once again, thanks for your valuable feedback!

Cheers,

Carles

> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>