>Yeah, we thought about that, and for more than just a few minutes.
>It seemed like it would require significantly more complex code
>for a relatively small win.

Complex?  Really?  I don't think so.  And there are cases
where the win is not small.  The mobile arena is a biggie.

[X11]

>Yah, but if we dynamically adjusted our idea of a "full-sized segment",
>wouldn't we eventually come to believe that the X11 tinygrams
>were full packets?  A very brief experiment shows lots of 32 and
>64 byte segments.

Huh???  I think that supports *my* position, not yours.

Your idea is to ack every two tinygrams, regardless.  My idea is to
keep an estimate of `effective MTU' and ack less; but how much less
depends on how recently the receiver has seen a non-tinygram.  My idea
(and its an idea, not a concrete implementation yet) cannot *possibly*
be any worse here.

> Obviously we could set a lower limit and lot
>lots of other stuff to complicate the calculation...

Huh?    What's so wrong with using a 576-byte minimum?

Isn't the requirement for accepting 576 byte IP datagrams still around
even in IPv6?  even there, some reasonable non-PMTU solution is needed
for IPmulticast.

And PPP? Would an upper bound on the ACK rate (lower bound on ACKed
size) of ever (2* 512 bytes) really be that bad?  I can see it's lower
than you might want over sub-576 PPP links.

But there, someone I'd say someone doing in_maxmtu has decided they
*do* want fragmentation, and to heck with it.  But that's another case
where I'd prefer the historic `negotiation' and to punt on in_maxmtu
altogether.  Same with adding extra headers for mobile encapsulation.

Until, that is, PMTU becomes ubiqutious. Which it isn't, and won't be
for some time.  (Maybe as long as SACK, mmm?.) I think you and Jason
have a real group-think problem going there: you do want PMTU, and are
prepared to ignore the lossage it causes non-PMTU hosts.  To the point
where, it seems, you refuse to even acknowledge the severity of the
problems it causes to people who aren't so fortunate.

I say ``problem for old hosts'', you two come back and say ``what about PMTU''?
I say ``problem for old hosts'' ,you two come back and say ``what about PMTU''?
Ad nauseam.   

The simple solution is for me to stop using NetBSD and to advise other
people here at Stanford to do the same thing.
Is that really what you want?


>>There *are* scenarios where it does make a clear difference.

>I'd like to hear more about these, and look at traces with
>various ACKing strategies. 

Don't know where to look, sorry.  In fact, Many of the traces in the
research community have actually used `ACK every packet'. Usually for
all the same self-clocking, easy ACKing, etc., arguments.


>I don't want to deluge the LAN
>with ACKs, but I similarly would like to ensure that we do enough
>ACKing to avoid stretch ACKs and similar problems.

I think everyone agrees with that.  I am just reminding you, not to
think only of LANs, but to think hard about both low-bandwidth links,
and links where there are hard constraints on absolute packet rate.

NAS and its HIPPI links is *not* the typical world.  It seems to me
that, just maybe, you might have lost sight of that.  

You may have trouble beleving this, but just last week I helped
someone set up an LPD queue on an IBM PC/RT. Which is still in active
use as a group server here. OK?


[TCP option]

>Yup.  We thought about this, too.  Think about SACK, which would
>be a great big win.  Who has deployed it?   How long has the RFC
>been out there?  Now think about yet another TCP option... :-)

Sure. Good point. SACK is only on the verge of seeing deployment.
It depends when you start counting; the original RFC, which was
ambiguous, or since the revival of a non-ambiguous proposal. The
latter is hitting deployment in just on 2.5 years.  It's a long-term
solution, sure, but architecturally I think it's the right one.

I took it as read that it'd take the normal amount of time to get
deployed; heck, look at multicast, that's taken ten years.


>[Just as an aside, Jason and I are both reasonably intelligent people
>who've spent much more than five minutes thinking about this stuff.
>I think it is a little bogus to throw out a few obvious ideas
>and ask for a patent on them, eh?]

Kevin, please. I didn't ask for a patent. It's purely about academic
credit.  I did say I thought the ideas were obvious.  That (obviusly)
means other people are likely to have thought of them.  I can't tell
how much you and Jason or anyone else have thought through them.

Then again, I thought relying on the 576-byte MTU as a lower bound on
the ACKing MSS was an `obvious' idea, and indisputably within in the
spirit of IPv6' approach to PMTU, but clearly I was wrong.

Kevin, my trouble is this: I know this stuff in more depth than,
perhaps, anybody else working on NetBSD. If I leave stuff out, I get
told nobody can follow what I'm saying.  If I don't leave stuff out,
I'm told I'm being condescending.  Even here, I throw out a simple,
straightforward idea, I *say* it's obvious, and you take offense.

And yet, just over one cup of bad coffee, I saw some ramifications
which (just going by your post) you missed.  What should I do?
It seems to me like I cannot win: whatever I do will piss somebody
off.  So, I *am* sorry I pissed you off.  I was just trying to help.

Should I stop?  If you'd rather I did, I will.