Subject: Re: perhaps time to check our TCP against spec?
To: None <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 04/07/1998 15:48:48
I'm catching up with email in reverse order, to avoid repeating
points, so sorry if I miss something...
>Even if the NetBSD host doesn't have PMTU turned on, the current
>scheme would still be a win if the host on the other side could do
>PMTU. Using the old scheme, we would only advertise a 576 byte
>MSS, and the other side would be limited to sending segments of the
>same size as ours. The ACK-every-second-packet fix makes
>it possible for us to get maximal receive performance when
>we are communicating with a PMTU-equipped host.
>I certainly think that this is arguable,
No, i think this mauch is pretty straightforward. I don't think I
disagree, given teh qualifications about PMTU.
The basic disagreement is about how prevalent PMTU is, and about
whether we should break existing behaviour in order to better
Negotiated-MSSS is known, relied-upon, existing behaviour. Go ask
Vernon Schryver. People have been told to rely on this behaviour for
for years before PMTU was heard of.
where we disagree is here:
>My enthusiasm for the new in_maxmtu MSS scheme (aside from
>the fact that it comes straight from RFC 1191) comes from
>my perception of the reality of multihomed hosts, asymmetric links,
>and mobility. I think that it is very likely that a connection
>could be issued from the Ethernet interface of Host A,
>and the return path could come back over the FDDI interface.
In my litle corner of the world, with Metricom radios, and old
FDDI-attached hosts which are not going to do PMTU anytime soon, the
perception is very different. Maybe things are different at NAS.
I have no way to know that ;)
But in_maxmtu *does* break existing behaviour and *does* break
existing setups. But what I am saying, and will continue to say, is
that breaking existing practice for the benefit of something that is
not pervasively deployed, and *may not even be under the control of
the NetBSD user*, is just not on.
NetBSD'S in_maxmtu has to be configurable. From my end, that much is
non-negotiable. And I still think the default should be off if the
default for pmtu is configured off (as it is now).
I hope where i'm coming from is clearer, now.