Set `tcp_base_mss` while enabling the MTU probing.

[k4yt3x]

Set `tcp_base_mss` while enabling the MTU probing.

[IceCodeNew]

rg -F 'mss' /etc

cat /proc/sys/net/ipv4/tcp_base_mss

1024

uname -a

Linux UK-akko 5.11.0-37-generic #41~20.04.2-Ubuntu SMP Fri Sep 24 09:06:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

---

I just find out that this configuration defaults to 1024 on my server OS. I'm not sure what this value is set to on other distros. But to have this configuration specified in this project should not harm.

[IceCodeNew]

min_pmtu - INTEGER
	default 552 - minimum discovered Path MTU
(Refer to: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt)

BTW there seems to be another related configuration.

Maybe not.

ip_no_pmtu_disc - INTEGER
	Disable Path MTU Discovery. If enabled in mode 1 and a
	fragmentation-required ICMP is received, the PMTU to this
	destination will be set to min_pmtu (see below). You will need
	to raise min_pmtu to the smallest interface MTU on your system
	manually if you want to avoid locally generated fragments.

	In mode 2 incoming Path MTU Discovery messages will be
	discarded. Outgoing frames are handled the same as in mode 1,
	implicitly setting IP_PMTUDISC_DONT on every created socket.

	Mode 3 is a hardened pmtu discover mode. The kernel will only
	accept fragmentation-needed errors if the underlying protocol
	can verify them besides a plain socket lookup. Current
	protocols for which pmtu events will be honored are TCP, SCTP
	and DCCP as they verify e.g. the sequence number or the
	association. This mode should not be enabled globally but is
	only intended to secure e.g. name servers in namespaces where
	TCP path mtu must still work but path MTU information of other
	protocols should be discarded. If enabled globally this mode
	could break other protocols.

	Possible values: 0-3
	Default: FALSE

I'm so confused...

[k4yt3x]

Sorry I've been a bit busy with my few assignments that were due.

I just find out that this configuration defaults to 1024 on my server OS. I'm not sure what this value is set to on other distros. But to have this configuration specified in this project should not harm.

Mine's also 1024. It seems like this has been the default in the newer kernels?

tcp_base_mss - INTEGER
	The initial value of search_low to be used by the packetization layer
	Path MTU discovery (MTU probing).  If MTU probing is enabled,
	this is the initial MSS used by the connection.

I think min_pmtu defines the lower boundary of PMTU discovering results. tcp_base_mss is where PMTU probes start at, which is what we really worry about here. Giving it a larger number should help speeding the process up a bit.

[k4yt3x]

I think I can put 1024 in. It doesn't seem like it will hurt.

[IceCodeNew]

Giving it a larger number should help speeding the process up a bit.

But it will hurt if there are some wacky devices in the network path.
Following the RFC seems the only sanity choice to me, after all the usual optimized MTU setting is 1200+, not far from 1024.

[IceCodeNew]

It seems like this has been the default in the newer kernels?

I do think so. But there are sayings that tell this setting is default to 512, which is written quite a time ago.
So I think we may better have this configuration specified to 1024 to give PMTU a safe land.

[k4yt3x]

But it will hurt if there are some wacky devices in the network path.

By "larger" I meant larger than 512, not larger than 1024. I'm fine with the way it is right now.