Kernel enforces MTU if set as initial [congestion] window size and leaves no config option, is that really good idea? How know that the "automtu" setting is off for an IPv4 NIC? Please correct me, thanks

[Tinker]

On 2015-03-29 13:50, Stuart Henderson wrote:
On 2015-03-29, Tinker <ti...@openmailbox.org> wrote:
How do I make TCP stack's initial window 10-50KB, so that I can burst
that amount of data without any interference from the TCP 
slow-start/RFC
3390 anti-congestion whatsoever?

OpenBSD already starts with 14600, see around line 3140 in tcp_input.c
if you'd like to experiment.


So the default Initial Window size is a copy of the NIC's MTU:

Isn't that a quite non-optimal setting for an Internet server, where 
your local Ethernet NIC's MTU size and "hardmtu" setting (i.e. max 
allowed configurale MTU) size has ***no correlation at all*** with what 
the initial congestion window is about?!


I understand that logic may work generally, but in my usecase with very 
crappy pingtimes and very reliable network infrastructure, the 
assumption that initial window size and MTU are the same setting just 
doesn't deliver, no?


Actually for a hack: If I just use IPv4 only, then it takes the sysctl 
mssdflt setting. But then, that is only if automtu is off, how do I know 
that it is off?


Thanks,
Tinker



The relevant pointers in the code are:

Row 3011 uses the sysctl mssdflt setting I presume "mssopt = mss = 
tcp_mssdflt".

Row 3066 uses the nic's MTU as initial window size (here: mss), if it is 
IPv4 and has automtu set.

Row 3074 uses the nic's MTU as initial window size (here: mss), if it is 
IPv6.

Row 3150 effectuates the initial congestion window setting: 
"tp->snd_cwnd = mss;"