>On Mon, 6 Apr 1998 22:01:39 -0700 (PDT) 
> Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:
>
> > >NetBSD does not ACK every 2*rxMSS.  It ACKs every two segments received,
> > >regardless of size.
> > 
> > Right. that's the ``more aggressive ACK'' policy.
> > Was that too hard to follow.
>
>Some (not just myself, mind you) consider it "just as aggressive as it
>should be".

Sure. Absolutely. I would probably be one of them.  If you're talking
about receiving max-MSS-sized packets for the interface the packets
arrive on, Id' definitely be one of them.  I'd only start to quibble
if the packets are ``short'', like shorter than a 576 IP-MTU would
allow.  It's not yet standard though, that was the point.


> > Unless you get NetBSD's nonstandard more-aggressive acking into the
> > IETF standards track.  Which might not be a bad idea, if people deploy
> > ideas like in_maxmtu in situations like the one above.
>
>It is the opinion of many in the TCPIMPL WG that it should be "ACK every
>two packets" not "ACK every 2*rxMSS", because, as I have said previously
>in this thread, the receiver CANNOT know the MTU of the peer's transmit
>path.  There are all sorts of reasons for this, such as assymetric routes,
>assymetric links (common in satellite applications), etc.

Sure.  And some people are even of the more extreme opinon that `ack
every packet' is better.  Including most of hte authors in the
teeny-tiny bibliography I posted.  I don't go that far myself.  Not
yet, anyway.

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.

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?

>> I need to get a clue?

>Absolutely.  I'm talking about -current, not 1.3.1, and certainly not
>.1.2G+patches. 

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

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


 (And, as I recall, "just committed" means "just before
>the LA IETF", which means it's been out there for about a week now...
>in fact, it was committed on March 24th...)

Again, that doesn't address the questions of topologies where
in_maxmtu loses.  Is there some reason you dont' want to answer that?


>In any case, the fix Kevin "just committed" really only affects you if
>you're a sender, and are using a source route to reach the peer.


That's npot what Kevin says.

>Somewhat
>before that, Kevin fixed a bug where, on retransmit, we'd end up sending
>a large segment followed by a very small one, because the size of the TCP
>options weren't properly accounted for (this was documented in known-problems)

That's a much longer-standing bug.