sftp performance problem, cured by TCP_NODELAY

[Chris Rapier]

Miklos Szeredi wrote:
>>> So TCP_NODELAY is already set for interactive sessions.  I hadn't
>>> noticed that.
>>>
>>> It's actually pretty stupid I think, as Nagle (TCP_NODELAY off) _only_
>>> makes sense for _interactive_ sessions.
>> It makes zero sense for interactive sessions - do you really want your
>> keystrokes delayed?
> 
> Over really slow links yes, that is the correct thing to do.  Just
> consider the immense overhead of sending a separate packet for each
> keystroke.
> 
> However nowdays it probably doesn't make much difference either way.
> 
> But I do think that Nagle was invented exactly for the interactive
> kind of traffic.

If you break out your copy of Stevens TCP/IP Illustrated you'll find 
that this is correct. However, its not really designed to address slow 
links as much as it was designed to address congested links. The Nagle 
algorithm helps reduce overhead (so you don't send a 40 byte packet with 
1 byte of useful information) and can increase the perceived and real 
efficiency of a network. Maybe there is some security reason dealing 
with traffic analysis to not use it though. However, if its just a 
matter of "well, the network is fat enough so it will forgive our 
inefficiencies" then that doesn't make a lot of sense. You never know 
what the congestion of the network will be unless you assume it to have 
infinite capacity.

>>> So it should be the other way round as it is currently.
>>>
>>> But unconditionally setting TCP_NODELAY should at least cure the sftp
>>> performance problem.  The patch in comment #9 looks fine.
>> We can look at turning Nagle off unconditionally after we get 4.3 out
>> the door.
> 
> Fine.  But just delaying this problem for ever is not the solution.
> And I can see posts from 2002 discussing exactly the same problem with
> sftp performance.

Better logic to control NODELAY usage makes sense. I never looked 
closely at this portion of the code but perhaps it could be triggered by 
a request for remote TTY.


>>> Longer term I think you should consider adding "NoDelay" and maybe
>>> "NoDelayInteractive" bool options, and _not_ setting nodelay on
>>> interactive sessions by default.
>> No, we won't be adding any stupid button for people to push.
> 
> I don't agree with that, but it's your choice.

I actually agree with Damien on this point. There shouldn't be a user 
setting. The software should be able to determine when NODELAY should 
and shouldn't be set. While it might be more difficult to create a 
generalized solution because of port fowarding issue a more specific 
solution that will capture 95% of the common usage situations should be 
feasible.