Re: Too aggressive TCP ACKs

> On Nov 10, 2022, at 8:01 PM, Scheffenegger, Richard <Richard.Scheffenegger@netapp.com> wrote:
> 
> This is the current draft in this space:
>  
> https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-rate-request/ <https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-rate-request/>
>  
> and it has been adopted as WG document at this weeks IETF, from what I can tell.

Thanks for that information !

>  
> So it has traction – if you want to give your feedback, please subscribe to the tcpm mailing list, and discuss your use case and how/if the approach aligns with this there.

Subscribed.

>  
> Richard
>  
>  
>  
> From: owner-freebsd-net@freebsd.org <mailto:owner-freebsd-net@freebsd.org> <owner-freebsd-net@freebsd.org <mailto:owner-freebsd-net@freebsd.org>> On Behalf Of Zhenlei Huang
> Sent: Donnerstag, 10. November 2022 09:07
> To: Hans Petter Selasky <hps@selasky.org <mailto:hps@selasky.org>>
> Cc: Michael Tuexen <michael.tuexen@lurchi.franken.de <mailto:michael.tuexen@lurchi.franken.de>>; freebsd-net@freebsd.org <mailto:freebsd-net@freebsd.org>
> Subject: Re: Too aggressive TCP ACKs
>  
> NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 
> 
> 
> On Nov 9, 2022, at 11:18 AM, Zhenlei Huang <zlei.huang@gmail.com <mailto:zlei.huang@gmail.com>> wrote:
>  
>  
> On Oct 22, 2022, at 6:14 PM, Hans Petter Selasky <hps@selasky.org <mailto:hps@selasky.org>> wrote:
>  
> Hi,
> 
> Some thoughts about this topic.
>  
> Sorry for late response.
> 
> 
> 
> 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!
>  
> In data centers, the bandwidth is much more and the latency is extremely low (compared to WAN), sub-milliseconds .
> The TCP window space is bandwidth multiply RTT. For a 30 GBit/s network it is about 750KiB . I think that is trivial for a
> datacenter server.
> 
> 
> 4.2.3.2 in RFC 1122 states:
> > in a stream of full-sized segments there SHOULD be an ACK for at least every second segment 
> Even if the ACK every tenth segment, the impact of delayed ACKs on TCP window is not significant ( at most
>  ten segments not ACKed in TCP send window ).
>  
> Anyway, for datacenter usage the bandwidth is symmetric and the reverse path ( TX path of receiver ) is sufficient.
> Servers can even ACK every segment (no delaying ACK).
>  
> 
> 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.
>  
> I'm OK with the current implementation.
>  
> I think upper layers (or application) have (business) information to indicate whether delaying ACKs should be employed.
> After googling I found there's a draft [1].
>  
> [1] Sender Control of Delayed Acknowledgments in TCP: https://www.ietf.org/archive/id/draft-gomez-tcpm-delack-suppr-reqs-01.xml <https://www.ietf.org/archive/id/draft-gomez-tcpm-delack-suppr-reqs-01.xml>
>  
> Found the html / pdf / txt version of the draft RFC.
> https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-pull/ <https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-pull/>
> 
> 
> 
> 
> 
> --HPS
> 
> 
>  
> Best regards,
> Zhenlei