>Is there any combination of TCP implementations (and options) under
>discussion here in which the peers WILL NOT interoperate? (i.e. No data
>will correctly pass between the hosts).
>
>If the answer is Yes, then I think we have an issue that must be dealt with
>in such a way that interoperation happens instead of not.
>
>If the answer is No, then we're arguing over performance optimization of
>transition cases, which, while useful, should not bar progress.

Erik,

It depends on how rigidly you define `interoperate'.  *If* you assume
fragmentation happens correctly and *if* the costs of fragmentation
are acceptable, then yes, I think Jasons' idea will work.
I think I've said that.

My point is, and always has been, that there are media (like Metricom
radios) and applications where the costs of fragmentation are simply
not accetapble, where in practice doing an in_maxmtu style
advertisment from the radio *does* break interoperablity.
And it does break the existing, expected practice for BSD systems.

A more subtle point is that in_maxmtu is not ncessary for PMTU.
in_maxmtu advertisments are themselves an optimization for
PMTU. According to Kevin Lahey, the consensus on tcp-impl is that the
conservative engineering decision is to _not_ do in_maxmtu MSS
advertisments, but to stick with the existing practice of using the
interface MTU.

My take is, ``be conservative in what you send'' says that's what we
should be doing by default and what we should be shipping as default
in our binary distributison.

It's fine with me if people in environments like NAS, with superbly
competent, highly skiled network support; richly-connected, high-MTU
media (FDDI or HIPPI); and no old systems to support, want to turn on
both in_maxmtu and PMTU.

I *dont* think it's good engineering to force in_maxmtu on everybody
regardless.  

Until I griped, that *was* Jason's position, as far as I can tell.
At least that has changed, there will be a knob, and I'm
grateful for that.

But I still think the right engineering decision is to turn off
in_maxmtu by default.  I think anything else violates ``be
conservative in what you send'', and I have yet to see a
justification for violating that.

Perhaps I'm misinterpreting, but the message I'm seeing boils down
(IMHO) to ``but we want to do it *here*, so it's going to be on by
default, and screw you!''.


>To make this absolutely clear - my first requirement is that interoperation
>happen. My second requirement is that progress (PMTU, etc) not be impeded,
>so long as the first rule is not violated.


Perhaps I'm wrong, but I dont' see how not doing in_maxmtu breaks
"making progress" with PMTU.  The RFC says it's optional.  And I think
Dennis Ferguson covered most of the issues here fairly well.