new sysctl tunable knob for tcpip

new sysctl tunable knob for tcpip

[Massimo Sala]

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 ?

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

best regards, Sala
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

new sysctl tunable knob for tcpip

[Massimo Sala]

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 ?

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

best regards, Sala

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 ?

netdev at 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

new sysctl tunable knob for tcpip

[valdis.kletnieks at vt.edu]

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.
-------------- 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/20170718/d66b2c3d/attachment-0001.bin 

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

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 

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... at vger.kernel.org
> Good luck!
> greg k-h


mlist : netdev at vger.kernel.org ?

Best regards, Sala