Re: [PATCH] tcp: add setsockopt to disable slow start after idle

Re: [PATCH] tcp: add setsockopt to disable slow start after idle

[Cristian KLEIN]

On 10/04/2010 07:13, David Miller wrote:
> From: Cristian KLEIN<cristiklein@gmail.com>
> Date: Sat, 10 Apr 2010 03:30:15 +0200
>
>> Allows user-space to override the sysctl
>> net.ipv4.tcp_slow_start_after_idle, on a per-socket bases, using
>> setsockopt().
>>
>> Slow start after idle can harm some scientific applications which
>> interleave computation and communication. Assume we have an iterative
>> applications, each iteration consisting of a computation and a
>> communication phase. If the computation phase takes long enough (i.e.
>> more that 2*RTT), the communication phase will always slow start and
>> might never reach the wire speed.
>>
>> This patch allows each application to disable slow start after idle,
>> just like we allow delay-sensitive applications (e.g. telnet, SSH) to
>> disable NAGLE.
>>
>> Signed-off-by: Cristian KLEIN<cristiklein@gmail.com>
>
> We specifically did not add a socket option for this facility.
>
> It is a very dangerous option to enable, and depends deeply
> upon the characteristics of your network and the paths by
> which remote hosts are reached.
>
> Therefore, only the system administrator can determine whether it is
> safe to enable this, and that's why it can only be changed via sysctl.
> Lettting arbitrary applications change this aspect of TCP is beyond
> dangerous.
>
> I will not be applying this patch.

Could you please explain me why it is dangerous? To me it seems that 
it's just like allowing applications to disable NAGLE or to choose a 
congestion control algorithm.

Re: [PATCH] tcp: add setsockopt to disable slow start after idle

[David Miller]

From: Cristian KLEIN <cristiklein@gmail.com>
Date: Sat, 10 Apr 2010 14:09:03 +0200

> Could you please explain me why it is dangerous? To me it seems that
> it's just like allowing applications to disable NAGLE or to choose a
> congestion control algorithm.

Because you can cause undue congestion to other people on the network
because you are believing path information that has been outdated and
has not been validated by sending data for a certain amount of time.

Re: [PATCH] tcp: add setsockopt to disable slow start after idle

[Cristian KLEIN]

On 11/04/2010 00:47, David Miller wrote:
> From: Cristian KLEIN<cristiklein@gmail.com>
> Date: Sat, 10 Apr 2010 14:09:03 +0200
>
>> Could you please explain me why it is dangerous? To me it seems that
>> it's just like allowing applications to disable NAGLE or to choose a
>> congestion control algorithm.
>
> Because you can cause undue congestion to other people on the network
> because you are believing path information that has been outdated and
> has not been validated by sending data for a certain amount of time.

I consider your argument an important concern, but I'm not quite 
convinced this patch is so bad.

An application which does not need this behaviour will continue to slow 
start after idle by default.

Without this patch, an application which needs this behaviour (i.e. not 
to slow start after idle) is forced to implement its own UDP-based 
protocol with all the congestion control, retransmission etc. Undue 
congestion might still occur.


If you don't agree with the above two points, would you consider 
accepting a patch with an allow_user_fast_start_after_idle sysctl?

Cristi.

Re: [PATCH] tcp: add setsockopt to disable slow start after idle

[David Miller]

From: Cristian KLEIN <cristiklein@gmail.com>
Date: Sun, 11 Apr 2010 20:45:10 +0200

> Without this patch, an application which needs this behaviour
> (i.e. not to slow start after idle) is forced to implement its own
> UDP-based protocol with all the congestion control, retransmission
> etc. Undue congestion might still occur.

Ask your system administrator to set the existing sysctl, because it
is a physical network attribute whether this behavior is safe or not.

And if it is safe, it is safe for all applications, there is no reason
for one application to ask for it and others to not.  If it's legal,
it helps all applications without exception.

Your attempts to tie this to NAGLE is complete nonsense.

NAGLE changes acking behavior, whereas this feature controls in what
way we trust congestion control information we've probed for in the
past.