Re: Too aggressive TCP ACKs

> On 26. Oct 2022, at 14:59, Tom Jones <thj@freebsd.org> wrote:
> 
> On Wed, Oct 26, 2022 at 02:55:21PM +0200, tuexen@freebsd.org wrote:
>>> On 26. Oct 2022, at 10:57, Tom Jones <thj@freebsd.org> wrote:
>>> 
>>> On Sat, Oct 22, 2022 at 12:14:25PM +0200, Hans Petter Selasky wrote:
>>>> Hi,
>>>> 
>>>> Some thoughts about this topic.
>>>> 
>>>> Delaying ACKs means loss of performance when using Gigabit TCP 
>>>> connections in data centers. There it is important to ACK the data as 
>>>> quick as possible, to avoid running out of TCP window space. Thinking 
>>>> about TCP connections at 30 GBit/s and above!
>>>> 
>>>> I think the implementation should be exactly like it is.
>>>> 
>>>> There is a software LRO in FreeBSD to coalesce the ACKs before they hit 
>>>> the network stack, so there are no real problems there.
>>>> 
>>> 
>>> Changing the ACK ratio seems to be okay in most cases, a paper I wrote
>>> about this was published this week:
>>> 
>>> https://onlinelibrary.wiley.com/doi/10.1002/sat.1466
>>> 
>>> It focuses on QUIC, but congestion control dynamics don't change with
>>> the protocol. You should be able to read there, but if not I'm happy to
>>> send anyone a pdf.
>> Is QUIC using an L=2 for ABC?
> 
> I think that is the rfc recommendation, actual deployed reality is more
> scattershot.
Wouldn't that be relevant? If you get an ack for, let's say 8 packets, you would
only increment (in slow start) the cwnd by 2 packets, not 8?

Best regards
Michael
> 
> - Tom
>