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@xxxxxx <valdis.kletnieks@xxxxxx> 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). > > > > _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
