Subject: Re: TCP_NODELAY in telnet (Re: CVS commit: src)
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-net
Date: 06/19/2003 20:22:27
    Date:        Thu, 19 Jun 2003 02:22:52 -0400 (EDT)
    From:        der Mouse <mouse@Rodents.Montreal.QC.CA>
    Message-ID:  <200306190658.CAA21871@Sparkle.Rodents.Montreal.QC.CA>

  | That's not clear to me, and apparently not clear to David either.  I
  | prefer to assume that when an RFC author writes "implement", the author
  | means "implement", and that if the author had meant something else
  | (such as "implement and use unless specifically disabled") that the
  | author would have _written_ something else.

The problem is that you're really not reading what is there.   You're
seeing "implement" and reading "write the code" - but that isn't what
it means, and cannot be.

Look at it again, see who or what is required to "implement" ...

What it says is:

	A TCP SHOULD implement the Nagle Algorithm

Now "A TCP" cannot possibly write code, or not any TCP I'm aware of.
That SHOULD is not directed at the person writing the TCP stack or
even the person/organisation distributing it, it is directed at the
TCP itself.

The only way that a TCP can "implement" the Nagle algorithm, that makes
any sense at all, is by that TCP not sending short packets while waiting
for an ack to an earlier short packet (ie: by putting into effect the
specification in rfc 896).

The existence of code which would do that, if only it was turned on,
is most certainly *not* implementing the algorithm in the sense it
must mean here.

  | As David put it, "If
  | [standards] meant 'do' they need to say 'do', rather than 'implement'".

But that is exactly what it does say, once you read it properly.

  | > If we default Nagle to disabled, we are in violation of the SHOULD,
  | > as written
  | 
  | Not if we implement it.

No, that is simply wrong.

Also note that in 112[23], SHOULD has a very strong meaning (unlike it
has perhaps been allowed to slide in more recent RFCs).

While these aren't the actual words used for the definition, what SHOULD
means in 112[23] is that "except in very peculiar circumstances, which
the authors can't do more than imagine ever existing, only a total
f*ckwit would ever do something different than this".

  | > An implemntation MUST provide a way to not do Nagle.
  | Right.  And I can't see how "don't turn it on" fails to satisfy that.

In the one in a million case where *TCP* not implementing Nagle is
the right thing to do, you're right.   But that's not NetBSD.

  | Now you're saying it too - you're using "implement" in a way different
  | from every other use of the word, apparently meaning something I would
  | phrase more like "implement and default to using".

That is *very clearly* what it means here, as that is the only way that
TCP (itself) can implement the algorithm, just having the code would be
NetBSD implementing the algorithm (one of NetBSD's developers) but wouldn't
be NetBSD's TCP stack implementing the algorithm.

If you're going to be pedantic about how you read the text, you need to
make sure you're getting it absolutely right.

  | DDB is commented
  | out in the NetBSD/sparc GENERIC config file (ie, it's not enabled by
  | default).  Would you say that we don't implement ddb on the sparc?

NetBSD has implemented it, but the sparc generic kernel has not.

  | And 4.2.3.4 doesn't say Nagle should be on by default, either, however
  | much you may want to read that into it, or however much you may believe
  | (perhaps even with cause) that Braden meant it to say that.

Quite simply, this is wrong.

kre