Re: 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.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 

Re: new sysctl tunable knob for tcpip

[valdis . kletnieks]

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).





pgpfZPVy6Sl82.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org

Re: new sysctl tunable knob for tcpip

[Massimo Sala]

I wish to suggest to developers to add this new knob :

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.

* 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 ).


>> q1) which is the right kernel m-list to discuss it ?

> net...@vger.kernel.org
> Good luck!
> greg k-h


mlist : net...@vger.kernel.org ?

Best regards, Sala

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: new sysctl tunable knob for tcpip

[valdis . kletnieks]

On Thu, 06 Jul 2017 09:23:46 +0200, Massimo Sala said:
> I have an idea about a new sysctl knob. It is under net.ipv4.

Step 0:  Identify whether it is even a good idea.  TCP/IP is tougher
than you think, especially when you get into congestion control.

Step 0.1: Figure out if your brilliant idea is also applicable to IPv6.

Step 0.2: You'll get more guidance if you explained what the knob is supposed
to do.


pgpWNrXkTCkZt.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: new sysctl tunable knob for tcpip

[Greg KH]

On Thu, Jul 06, 2017 at 09:23:46AM +0200, Massimo Sala wrote:
> I have an idea about a new sysctl knob. It is under net.ipv4.
> 
> q1) which is the right kernel m-list to discuss it ?

net...@vger.kernel.org

> 2) any suggestion how to gain the critical mass of consensus ?
> 
> 3) at first : is it mandatory to code the patch ?
> optional ... but better for 2) ?

Mandatory, we don't discuss "ideas", but only "implementations".

Good luck!

greg k-h

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies