Nagle & delayed ACK strike again

[Miklos Szeredi]

> >>My personal stance is that 99 times out of ten, if an end-user 
> >>application speeds-up when it sets TCP_NODELAY, it implies the end-user 
> >>application is broken and sending "logically associated" data in 
> >>separate send calls.
> > 
> > 
> > You tell me, is X protocol broken?  
> 
> Likely not - the discrete mouse events which are usually cited as the 
> reason X needs TCP_NODLEAY are not logically associated.  Hence that is 
> the 100th situation out of 10 rather then the 99.
> 
> > Is SFTP broken? 
> 
> Depends - is it writing logically associated data to the connection in 
> more than one send call?

No.  They are logically separate calls.

> > I don't think
> > SFTP more broken than any other network fs protocol.  The slowdown
> > happens with a stream of WRITE requests and replies.  If the requests
> > weren't acknowledged, there wouldn't be any trouble, but
> > acknowledgements do make sense for synchronous operation.
> 
> Do you have some system call traces and/or packet traces we could look 
> at?  If the write requests and replies are each single send call they 
> probably qualify as the "X exception"

Yes this is the case.  It's the symmetric counterpart of a READ
message pair, where the request is small and the reply is large.  In
that case the client needed TCP_NODELAY to solve the delayed ACK
interaction problem.

With the WRITE is the opposite, the request is large and the reply is
small, and now TCP_NODELAY is needed on the server.

In both cases the request and the reply are sent to the socket with a
single write() call.

To me it still looks like the use of Nagle is the exception, it has
already been turned off in the server for

  - interactive sessions

  - X11 forwarding

and it will need to be turned off for

  - SFTP transport

  - IP tunnelling

  - ???

Is there any transported protocol where Nagle does make sense?

Miklos