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

On Sat, May 2, 2020 at 8:21 PM Vidhi Goel <vidhi_goel@apple.com> wrote:
>
> Hi Carles,
>
> >> 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.
> >
> > Agreed!
> >
> > By the way, in the next draft update, we will add that, despite its
> > "Experimental" status, ABC is supported in many implementations.
>
> Some time ago, I had brought up this same problem with ABC (RFC 3465) that increasing by at most one MSS during slow start makes the growth some what non-exponential in cases where ACK ratio < 1 (for example, receivers doing GRO or ACK compression, ACK losses etc). To allow an exponential growth, we should certainly increase congestion window by the amount of bytes ACKed (what Linux does).

+1
I do want to mention that there's a legit concern of always
increasing based on #bytes: slow start (or generally congestion
control) can be more bursty with stretched-ACKs. IMHO idle-restart
bursts are just as bad and probably even more frequent with many TCP
senders disable slow-start after-idle and don't bother to pace. The
best form to de-burst is through (good) pacers like Linux's fq/pacing.
In other words congestion control and burst control should not be
juggled together via only congestion window changes.


>
>
> Vidhi
>
> > On May 2, 2020, at 1:34 AM, Carles Gomez Montenegro <carlesgo@entel.upc.edu> wrote:
> >
> > Hi Yuchung,
> >
> > <snip>
> >
> >>> 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.
> >
> > Agreed!
> >
> > By the way, in the next draft update, we will add that, despite its
> > "Experimental" status, ABC is supported in many implementations.
> >
> > <snip>
> >
> > Thanks,
> >
> > Carles
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
>