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".

 > 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.

Given that the receiver can't know what the peer considers a "maximum
segment to send", and the receiver is essentially responsible for keeping
the ACK clock going, the "ACK every two packets" is a good policy.

...which makes sense, given congestion is usually measured in packet count,
not packet size.

As for making IETF standards track... As far as I know, known-problems
is informational only.  I'm not sure what might happen wrt. to changing
the definition of delayed ACKs.  In any case, it was discussed during the
Munich and DC meetings.

 > Where, if things break as I think they do, it suggests the in_maxmtu
 > thing really has not been suifficently well thought-out.
 > 
 > 
 > > > Is that in 1.3.1 or not?
 > 
 > >If he "just committed" it, obviously it's not.
 > 
 > So, are you still saying ``where's the problem?'' and that
 > I need to get a clue?

Absolutely.  I'm talking about -current, not 1.3.1, and certainly not
1.2G+patches.  (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...)

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.  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)

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