_I would like to have additional capability of setting arbitrary options on routes which will be affective upon pod creation.
Specific ip route options of interest is quickack_
Proposal i based on following link.
https://man7.org/linux/man-pages/man8/ip-route.8.html - OPTIONS := FLAGS
Applications running in container often can not be changed programatically but network performance issues can be controlled on kernel level.
The 40ms delay in responding to ACK is an method built into the Linux IP stack to improve network performance.
When a participant in a TCP conversation has an ACK to send, the participant is acknowledging some data that has been received. That receiver will very likey have a reply to the data it just received.
The linux kernel will delay the outgoing ACK by up to 40ms to allow the reply to queue, then send both the reply and the ACK together.
This can be controlled/overide in two ways:
At the application level with the TCP_QUICKACK socket option. See man 7 tcp for further details. This option needs to be set with setsockopt() after each operation of TCP on a given socket.
In newer kernel route level with quickack 1 on the end of a route, eg:
ip route change default via 10.0.0.1 quickack 1
AWS-CNI Feature Proposal
Is your proposed feature related to a problem?
No.
Describe the feature you'd like
_I would like to have additional capability of setting arbitrary options on routes which will be affective upon pod creation. Specific ip route options of interest is quickack_ Proposal i based on following link. https://man7.org/linux/man-pages/man8/ip-route.8.html - OPTIONS := FLAGS
(Optional) Describe your proposed solution
You should extend route class: https://github.com/aws/amazon-vpc-cni-k8s/blob/9b380da51f9ba6e571656be83d82d80f275b6026/pkg/ipwrapper/ip.go#L38 with OPTIONS and possible FLAGS from https://man7.org/linux/man-pages/man8/ip-route.8.html page.
Motivation
Applications running in container often can not be changed programatically but network performance issues can be controlled on kernel level.
The 40ms delay in responding to ACK is an method built into the Linux IP stack to improve network performance.
When a participant in a TCP conversation has an ACK to send, the participant is acknowledging some data that has been received. That receiver will very likey have a reply to the data it just received.
The linux kernel will delay the outgoing ACK by up to 40ms to allow the reply to queue, then send both the reply and the ACK together.
This can be controlled/overide in two ways:
At the application level with the TCP_QUICKACK socket option. See man 7 tcp for further details. This option needs to be set with setsockopt() after each operation of TCP on a given socket.
In newer kernel route level with quickack 1 on the end of a route, eg: ip route change default via 10.0.0.1 quickack 1
Regards, Goran.