In message <199804070501.WAA06195@Kowhai.Stanford.EDU>Jonathan Stone writes
>You can't argue it will be
>applied elsewhere, like in the scenario I posted just before:
>
>   --FDDI ring A---
>       |
>     Host A
>       |
>     --------------------------  Ethernet ----  router R
>                                                  |
>                                                  |
>                                             --FDDI ring B---
>                                                      |
>                                                      |
>                                                      |
>                                                   Host B

Okay, this will obviously result in fragments on the Ethernet
when Host B is sending to Host A, given the current NetBSD
implementation of MSS, and no pmtu.  The older, "negotiated"
MSS scheme would prevent this.

A similarly contrived topology could result in the same behavior,
using either scheme:

Host C                Host D
   |                    |
 -- FDDI ring A --    -- FDDI ring B --
   |                    |
 router R              router S
   |                    |
  ---------- Ethernet --------


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.
If we advertise only the Ethernet MTU, we'll never get to
use the FDDI MTU, even if all traffic goes that way.
And while this doesn't seem very likely in the LAN,
it sure seems possible on the Internet (based on Vern Paxson's
recent stuff on routing asymmetry).

Similarly, what if I begin a connection from home, over
a PPP connection with a 296-byte MTU, then switch over to
Metricom with a 1200-byte MTU for the bike ride to work, and
finally plug my laptop in on the Ethernet which has an MTU of
1500 bytes?  I'd sure hate to be stuck with an MSS of 296!

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, so I'm ready for
more input from other NetBSD users.  I want our stack to be
both correct and performant!

Kevin