Skip site navigation (1)Skip section navigation (2)
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>