On Mon, 6 Apr 1998 23:15:54 -0700 (PDT) 
 Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

 > Sure.  And some people are even of the more extreme opinon that `ack
 > every packet' is better.  Including most of hte authors in the

...and, in fact, delayed ACK is a "may", not a "must", or even a "should".

 > But the in_maxmtu stuff: ``It depends''.  If you _do_ assume non-PMTU
 > hosts, then there *are* circumstances where the behaviour you suggest
 > *is* (relative to the old behaviour) broken.

Before I assume _anything_, I want to know which host you're talking about
when you say "assume non-PMTU hosts".  Us, or the peer?

 > One example is the most-recent topology i posted.  And exactly the
 > same issue arises if you have a single-homed Ethernet host talking to
 > a mobile host with a wireles MTu that's smaller than the wired MTU.
 > I still think the in_maxmtu thing is good for PMTU, but for non-PMTU
 > peers, it's broken.  
 > 
 > Did you discuss this to anybody from the mobile community?

It doens't really matter if I did or didn't.  In your ether+radio
example, even the "traditional" code would have been bounded by the
MTU of the outgoing interface!

(And, for the record, the MOBILEIP chair attents TCPIMPL meetings, and I
go to the MOBILEIP meetings if I don't have a conflicting session.)

 > This isn't current-users, Jason. It's fair to say ``the code is
 > broken'' here and refer to relased code.

Fine, and I stated quite early on in the thread that I was talking
about NetBSD-current.  I don't run releases, personally.  I live in
a development world, so I'm constantly running development code.  Cope.

Eventually, all of the recent recent recent changes will make it into
the netbsd-1-3 branch for another patch release.  1.3.1 actually included
several TCP fixes.

 > And you still haven't answered the topology issues.  Are you just
 > constitutionally incapable of acknowledging there are problems?

...probably because I was out getting dinner, or something.  "Read the
mail I just sent you."

 > That's npot what Kevin says.

Funny, it's what the source-changes archive says, assuming you're talking
about what I think you're talking about (what _are_ you talking about,
anyway?).

Oh, I forgot, you don't read source-changes.  "Oh well."

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939