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.kletni...@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
