On Wed, Jun 18, 2003 at 04:07:15PM -0700, Jonathan Stone wrote:
> We seem to be talking past each other.
> 
> Perry _did_ explicitly open the idea of making TCP_NODELAY the
> default. That change would clearly violate the SHOULD in RFC 1122,
> that hosts SHOULD implement the Nagle algorithm in their TCP.  To
> which I responded that Perry's suggestion would violate a SHOULD in
> RFC-1122. (which I mistyped as 1123, but Mouse figured that out).
> Perry has been silent  about the idea since then.

Sure, and I'm only concurring with Mouse that _textually_, we could do
that, and only violate a SHOULD, not a MUST.

In _actuality_, taking the intent of the authors into account, and
attempting to determine what they meant to say is valid - at least as
far as strengthening a standard, but not to contradict it, of course.

As usual with NetBSD as well, any change of that magnitude would need a
thorough investigation - more than just "I have one app that works
better this way"... "Hey, I have one too."

Earlier today, I was saying to someone "X.25 was built on a premise of
low bandwidth and high latency. Networks aren't like that much now,
which is why it's not used."  It's possible that some of the premise's
for Nagle aren't still valid, so asserting anything about how/why it was
written/interpreted the way it was for X years may not relate to today
at all.

> Mouse's reading, OTOH, is that implementing Nagle, and having Nagle
> default to off, follows both the SHOULD and the MUST. To me, that
> reading is completely off the wall: it fails a `reasonable man' test.
> (Bob Braden would have to be an *un*reasonable man, to have intended
> Mouse's reading, given the surrounding text of RFC-1122.)

Sure, and that agrees with my statement above, about 'in _actuality_'.

> again, if you *really* want to run that reading by Bob Braden, go ahead.
> But as I see that reading as more-or-less implicitly suggesting
> that Bob, himself, is not reasonable, then (just personally) I'd
> prefer that you not associate NetBSD with such a request.

As I said - I didn't propose making the change (I guess Perry did). When
you said this in the ealier mail, I didn't see any way to read it other
than ``That idea is so dumb, don't associate NetBSD with it''. Which
seemed to be a put-down to me, for something I hadn't suggested.

In general, I like to test things thoroughly. There could be a time to
ask the RFC authors about things - at the very least, that would be
after enough testing was done to show that enough has changed about the
network since the RFC was written that the majority of applications
would be better off without Nagle, than with it. That keeps the onus
where it belongs - avoiding change for the sake of change, and only
accepting well-justified, actual, improvements.

> You and Mouse apparently see it very differently. Perhaps that
> reflects how the Internet and the IETF (and the audience reading RFCs)
> have changed over the last 15-odd years. Which doesn't' say anything
> about your intelligence, so much as your background. If you are
> genuinely reading RFC-1122 so that a TCP which implements Nagle where
> Nagle is off by default is in conformance with RFC-1122, then (saying
> nothing about your intelligence per se) you're not particularly
> well-versed at reading RFCs.

I haven't read that RFC in it's entirety in years (I'd hazzard a guess
at ~1994). No one pasted any arguments about other content beyond the
one paragraph with the explicit SHOULD and MUST for 'enable' and 'allow
disable'. I was simply saying that from the text shown, I could accept
and agree with Mouse's logical reduction. I saw this as a logic
discussion, rather than a discussion of whether to make a change in
NetBSD's defaults, since the later hasn't been backed up adequately to
be seriously considered.

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
Net Musing #5: Redundancy in a network doesn't mean two of everything and
half the staff to run it.
					      - Tomas T. Peiser, CET