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