Date: Wed, 4 Dec 2019 14:11:02 +0000 From: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com> To: "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org> Subject: acknow on cwr Message-ID: <SN4PR0601MB3728E9BBCD37BC2F7B11097F865D0@SN4PR0601MB3728.namprd06.prod.outlook.com>
next in thread | raw e-mail | index | archive | help
Hi guys (gals?), While further looking into DCTCP bugs and oddities, I was pointed to these = two linux patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3D9aee40006190 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?= id=3Dfd2123a3d7527d4c7092633d55e877c0cc1d84a3 The gist of this is as follows - and likely holds true for RFC3168 also: When a tcp sender reduces cwnd due to CE marks, it is possible to end up wi= th very small cwnd (<2 mss). When the next packet is sent, with the CWR fla= g, the receiver will often wait for another packet before sending an ACK af= ter the delack timer expires. This can effectively drive up the high-perce= ntile latency on request-response type interactions. The above was found specifically for flows using dctcp, most likely as the = cwnd in dctcp environments is more likely to collapse to very small values = - but the patch seems to be generic also for rfc3168 sessions... Any strong opinions if this fix should be specific to dctcp in fbsd, or a g= eneric ecn improvement? Note that RFC3168 is silent on this particular topic (if CWR should trigger= an immediate ACK or not). Best regards, Richard Scheffenegger
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SN4PR0601MB3728E9BBCD37BC2F7B11097F865D0>