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

[Yuchung Cheng <[e-mail]>]

On Fri, May 1, 2020 at 1:56 AM Carles Gomez Montenegro
<[e-mail]> wrote:
>
> 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.
I agree. We in fact implemented Linux to increase cwnd by the exact
amount sequence (in unit of packets) so slow-start increase function is
regardless of ack-thinning effect but purely based on amount
delivered. This has an important effect on
Wireless as the other ack talk mentions. It also helps in case of ACK
losses or reordering.




>
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
>
>