new sysctl tunable knob for tcpip

[Massimo Sala]

Ok, I understand the lesson.

Now the practice : I want to set a 200 seconds timeout, valid on all
the interfaces, on all the connections.

How can I calculate the value to set tcp_retries2 to ?

best regards, Sala

On 31/07/2017, valdis.kletnieks at vt.edu <valdis.kletnieks at vt.edu> wrote:
> 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).
>
>
>
>