[PATCH] Added NoDelay config option and nodelay subsystem option

[Nicolas Williams]

On Tue, Jan 29, 2002 at 06:32:23PM +0100, Tobias Ringstrom wrote:
> On Tue, 29 Jan 2002, Nicolas Williams wrote:
> 
> > Yes. But the problem probably is that the old Nagle algorithm and TCP
> > congestion control in general probably needs revision to really work in
> > newer networks.
> 
> Why would Nagle not work well for pty sessions over modern networks that
> happen to have a high latency link?

*shrug*

That's the complaint I see when I search for this on google.

> As for improved TCP congestion control, I thought ECN would help a lot 
> once it is in wide-spread use.

That's just it.

> It's not very easy.  Delaying the window adjustment packet, as described
> below, and implementing a timeout would take some time.  I'm not very keen
> on doing it.  It would be a very good thing, no doubt.

Hmmm.

> > Well, not triggering Nagle seems to me like a more noble thing to do
> > than just disabling it.
> 
> What I'm saying is that when we have overlapping requests, we need to
> disable nagle, even if we could merge the window update packets with the
> requests or responses.  Let's see if I can explain it.  Consider a channel
> with a 2 s RTT, infinite throughput, infinitely fast computers, no window
> updates, and a Nagle timeout of 0.2 s.  The write column is the time the 
> process calls write(), and the send column is the time the TCP stack 
> releases the packet on the wire.  Req is a small request packet (<<MSS), 
> and Rsp is a large response packet (>>MSS).
> 
> Write  Send   Signal     Arrival
> -----------------------------------

[...]

> Did I get it right, or did I miss something?  As you can see, transmitting 
> four data packets took 4.4 seconds.  Without Nagle, it would have taken 4 
> second.

yes, 200ms is way too much nowadays. Which is why Nagle needs updating,
and why Nagle could be done much better at the SSHv2 layer...

> /Tobias


Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.