Burst Mitigation

Scheffenegger, Richard Richard.Scheffenegger at netapp.com
Thu Jan 31 18:02:00 UTC 2019


I was wondering about the 2001 patch removing transmission burst mitigation.


The comment added only makes sense, when dealing with a client that exclusively sends out time-delayed ACKs, IMHO.

Comparing this with NetBSD and OpenBSD, both variants still retain this burst mitigation, never sending out more than 4 (TSO) segments per ACK.

OTOH, the concern I can think of at this time and age would be interoperability with RACK or aggressive LRO.

As a lower bound, it is expected to receive at least 2 ACKs per window - thus the largest possible burst may be (cwnd/mss/2 segments.

At the same time, the burst size should be limited when the pipe is completely empty (where currently, a burst of size cwnd/mss is allowable, leading to self-inflicted losses.

Perhaps to find a reasonable middle ground, revive maxburst with the following formular (adjusted for integer arithmetic):

Maxburst = max(initcwnd, 

((1 - ((Pipe - cwnd/2)^2 / (cwnd/2)^2)) * cwnd/2)/mss

Or, to not have any multiplications:

((1 - (abs(pipe - cwnd/2) / cwnd/2)) * cwnd/2)/mss


With pipe simplified to (snd_max - snd_una).

The idea is, that when pipe is fairly full, a sudden jump in cwnd doesn't cause extremely excessive burst, and also when pipe runs empty, the next burst to ramp up the transmission is not as extreme as it can be currently.

With a lower limit of initcwnd this can still be potentially at least 5x more aggressive than slow start. But dumping 1 MB @ line rate after pipe has drained would be mitigated at least, at least reducing the extent of self-inflicted drops.

More information about the freebsd-transport mailing list