> On Nov 10, 2022, at 8:01 PM, Scheffenegger, Richard > <richard.scheffeneg...@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-...@freebsd.org <mailto:owner-freebsd-...@freebsd.org> > <owner-freebsd-...@freebsd.org <mailto:owner-freebsd-...@freebsd.org>> On > Behalf Of Zhenlei Huang > Sent: Donnerstag, 10. November 2022 09:07 > To: Hans Petter Selasky <h...@selasky.org <mailto:h...@selasky.org>> > Cc: Michael Tuexen <michael.tue...@lurchi.franken.de > <mailto:michael.tue...@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.hu...@gmail.com > <mailto:zlei.hu...@gmail.com>> wrote: > > > On Oct 22, 2022, at 6:14 PM, Hans Petter Selasky <h...@selasky.org > <mailto:h...@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
