acknow on cwr

Scheffenegger, Richard Richard.Scheffenegger at netapp.com
Wed Dec 4 14:11:09 UTC 2019


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=9aee40006190
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd2123a3d7527d4c7092633d55e877c0cc1d84a3

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 with very small cwnd (<2 mss). When the next packet is sent, with the CWR flag, the receiver will often wait for another packet before sending an ACK after  the delack timer expires. This can effectively drive up the high-percentile 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 generic ecn improvement?

Note that RFC3168 is silent on this particular topic (if CWR should trigger an immediate ACK or not).

Best regards,

Richard Scheffenegger



More information about the freebsd-transport mailing list