new sysctl tunable knob for tcpip

[valdis.kletnieks at vt.edu]

On Mon, 31 Jul 2017 15:16:34 +0200, Massimo Sala said:
> I wish to suggest to developers to add this new knob :

Note that most of the existing knobs were chosen fairly carefully, and that
sometimes, the values chosen aren't immediately obvious, because they have
to also take into account second-order effects.

To quote RFC1925: "Some things in life can never be fully appreciated nor
understood unless experienced firsthand. Some things in networking can never be
fully understood by someone who neither builds commercial networking equipment
nor runs an operational network."

> tcp_retries2_time - INTEGER
> 	This value influences the timeout (seconds) of an alive TCP connection,
> 	when RTO retransmissions remain unacknowledged.
>         RFC 1122 recommends at least 100 seconds for the timeout,
> 	which corresponds to a value of at least 8.
>
>
> Rationale :
> * I see too many abuse of tcp_retries2, because even if you check the
> RTO, it will change with different connections, routing, etc.

Note that this is actually a good reason *NOT* to add such a knob - if you
set it down to (say) 10 seconds, it can cause a connection to fail under some
circumstances (for instance, if multiple routers along the route need to ARP
for the next-hop router, or if there's heavy bufferbloat issues along the path).

The value was *intentionally* set fairly high, even for RFC1122 days (I was
around for that).  At the time, a 56K leased line was common for a college
or small corporation, and if you had *lots* of money, a 1.544mbit/sec T1. If
you wanted a router, you built your own out of a MicroVAX with 2 network
interfaces, or bought from Proteon or Bay, and you were just starting to
think about whether this 'cisco' company would make it or not...

And even then, the default value for the timeout was chosen to guarantee enough
retransmits to statistically rule out packet loss or temporary line noise.

Please explain your environment where you're seeing enough SYN retries to
matter - usually this isn't an issue unless somebody is intentionally SYN-flooding
you, at which point they're going to ignore that knob anyhow (plus the SYNs
are statistically most likely to be coming from pwned Windows boxes).

> * It will be friendly and I think better to document an absolute value.
> See other parameters with two knobs ( example : dirty_ratio,
> dirty_ratio_bytes ).

Actually, it has a good chance of being *UN*friendly - if the connection fails
because the low-lowered timeout is exceeded, there will probably be a retry
of the connection, generating *more* SYN traffic.

And to cite RFC1122, section 1.1.2(d) again:

         (d)  The System must tolerate wide network variation.

              A basic objective of the Internet design is to tolerate a
              wide range of network characteristics -- e.g., bandwidth,
              delay, packet loss, packet reordering, and maximum packet
              size.  Another objective is robustness against failure of
              individual networks, gateways, and hosts, using whatever
              bandwidth is still available.  Finally, the goal is full
              "open system interconnection": an Internet host must be
              able to interoperate robustly and effectively with any
              other Internet host, across diverse Internet paths.

              Sometimes host implementors have designed for less
              ambitious goals.  For example, the LAN environment is
              typically much more benign than the Internet as a whole;
              LANs have low packet loss and delay and do not reorder
              packets.  Some vendors have fielded host implementations
              that are adequate for a simple LAN environment, but work
              badly for general interoperation.  The vendor justifies
              such a product as being economical within the restricted
              LAN market.  However, isolated LANs seldom stay isolated
              for long; they are soon gatewayed to each other, to
              organization-wide internets, and eventually to the global
              Internet system.  In the end, neither the customer nor the
              vendor is served by incomplete or substandard Internet
              host software.

              The requirements spelled out in this document are designed
              for a full-function Internet host, capable of full
              interoperation over an arbitrary Internet path.

(And I'll overlook how much *other* stuff from RFC1122 and RFC1123 has
gone by the wayside in the 28 years since - several pages of 1122 are
obsoleted by CIDR, and the requirement "MUST discard packets with an
IP version != 4" is an obvious crock when many places are doing more
IPv6 traffic than IBv4).



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170731/ddcf9ffc/attachment.bin