In message <199804070501.WAA06195@Kowhai.Stanford.EDU>Jonathan Stone writes
>
>On  "Mon, 06 Apr 1998 21:27:43 -0700",  Jason Thorpe <thorpej@nas.nasa.gov>
>writes:
>
>>On Mon, 06 Apr 1998 19:05:53 -0700 
>> Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:
>>
>> > Yes, that, and that merely RFC-conformant hosts (or NetBSD hosts
>> > without the more aggressive ACK changes) would only be ACKing2*MSS.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>> > Which could be a heck of a lot more than twice the actual `MSS'
>> > derived from the interface.
>
>>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.
>
>And, as I said, that's a nonstandard. You can't argue it will be
>applied elsewhere, like in the scenario I posted just before:

I think that anything else is broken in the face of pmtu and
asymmetric routing.  The packet sizes you are likely to get can
have nothing at all to do with your advertised MSS (well, they 
better be less than it).  If you sent an MSS of FDDIMTU (~4K),
and wound up communicating over a PPP link with an MTU of 512 bytes,
using pmtu, you'll ACK every 8 packets!

RFC 1122 says that at least every 2nd full-sized segment MUST be ACK'd
(it says SHOULD in the text, MUST in the table of requirements).
This certainly doesn't prevent us from ACKing more frequently,
and sorta leaves the definition of "full-sized segment" dangling.
In the presence of pmtu, I'd argue that full-sized segment is
nearly impossible to define, and that ACKing every second segment
is a win.

I was originally unsure about ACKing every second segment -- it
seemed like a hack.  As I've thought about other cases, I've
come to feel better about it.  Even if we are sending tinygrams,
Nagle will prevent more from being sent until we ACK the initial
tinygram, which means that we don't have a problem there.
If Nagle is turned off and we're getting deluged with tinygrams,
well, then, it doesn't seem like that great a sin to be sending
back an ACK for every two tinygrams.

The one case I'd worry about is on very asymmetric links.
Does anyone have any ideas about that?  I know that there has
been *some* research, but how much, and what should we do
about it in NetBSD?

>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.
>Where, if things break as I think they do, it suggests the in_maxmtu
>thing really has not been suifficently well thought-out.

Hmmm.  I think that we're well within the spec, here.  Microsoft
says that alot, too, so I'm not gonna hue to that line and never
waver, but I think that the ACKing behavior is right on.  I mean,
Linux does it...[*] :-)

Kevin
--
[*] Yeah, yeah, I just threw it in to get y'all excited...