Subject: Re: internet draft on suggested mod to the Nagle algorithm

From: Vernon Schryver <[email-masked]>
Date: Thu, 4 Feb 1999 07:40:12 -0700 (MST)

> From: der Mouse  <[email-masked]>

> ...
> > that do support TCP_NODELAY.  Instead, let's wait for the few, if
> > any, announcements of those that don't.
>
> I suspect this won't work very well.  I feel quite sure that having a
> representative on tcp-impl correlates positively, and probably fairly
> strongly, with having a relatively decent implementation.  Thus, the
> people who could truthfully chime in as you request - even assuming
> they'd be willing to publicly admit their failing - are the people who
> probably won't see the question.

That's all quite right, but the problem applies even more to the other
tactic of collecting notes about systems whose advocates claim work
correctly.

There's also the issue of why the IETF cares whether any particular
implemetation does or does not implement TCP_NODELAY.  It's one thing for
to define a standard, and quite another thing to monitor, test, or
otherwise worry about the compliance of every implementation deployed or
announced.

> The only way I expect to see "<foo> doesn't do this right" here is from
> someone who wrote code that tried to disable Nagle (eg, TCP_NODELAY)
> and then discovered in a packet trace that it was happening anyway.

In general, that's also probably true.  However, if you have an application
which uses TCP_NODELAY because it is undesirable for it to follow the
rules (e.g. does things like write-write-read-...) and so gets hit by the
Nagle+delayed_Ack interaction, you probably won't need to packet trace to
have the problem brought to your attention.  The performance effects are
hard to miss.

I have such an application, but it wouldn't be helped by the proposal
because its naughty writes are too small.  It still needs TCP_NODELAY.
Such is life.

Vernon Schryver    [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 04 Feb 1999 09:14:43 -0800

> because its naughty writes are too small.  It still needs TCP_NODELAY.

Maybe this is an irrelevant thread, then. Obviously there will be some
apps that would still need to disable the modified Nagle. That does not
mean the proposal is invalid, but probably means that the question I
asked is irrelevant.

I suppose the question ought to be: how would the modified Nagle affect
everyday applications? I can't really think of any situations in which
the proposal would hurt throughput. I'd like to see some testing of
typical apps to verify it though. Greg, do you have data showing
different kinds of apps over extended periods that are benefitted by
this, or that (more important) are hurt by it?

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com