sockets: bump socket buffer limit

[tuexen]

Summary

Bump it to 16 MB to allow higher throughput with default configurations.

[jtl]

My main concern about these three revisions is that they are somewhat susceptible of remote manipulation, and that could make it easier to DoS a server. However, I view that as a tradeoff that the user needs to make, and think an appropriate release note should suffice to warn about these issues.

[glebius]

In D52873#1207907, @jtl wrote:

My main concern about these three revisions is that they are somewhat susceptible of remote manipulation, and that could make it easier to DoS a server. However, I view that as a tradeoff that the user needs to make, and think an appropriate release note should suffice to warn about these issues.

I raised the same concerns on all the discussions we had on that on the transport call. We still decided to proceed with the change, to match modern network speeds and other OSes.

The rationale is that we aren't raising the default socket size, but the maximum it can autoscale to. So, for attacker to succeed, they need to have a very good connection to the victim and work a little bit on growing the window on every separate connection [1]. However, those connection share the bandwidth. This makes attack even more difficult. I never heard of such attacks in the wild. If attacker owns a large distributed botnet of poorly performing bots (a usual case), of course attacking the default buffer is the way to go.

[1] I have a patch in queue that enables bandwidth products to be used from TCP hostcache. It has been tested by our team, but awaits TCP team approval for over a year already. Combination of these two changes will make us more vulnerable to this kind of attack - attacker will need not work on the window for every connection.

This all together calls for a mechanism to shrink a buffer that has once grown. We have agreement with lstewart@ that this needs to be done, just ENOTIME.