In message <19990929030333.A14856@acm.org>, Feico Dillema writes:

>I think (but am certainly not sure) that FreeBSD has PMTU discovery on
>by default now. That's how I discovered it was off by default in
>NetBSD. I wondered what was the cause of the performance difference
>between FreeBSD and NetBSD on a 100Mbs Etherlink. Switching on 
>PMTU disc. seemed to make up for most of it.

Um.  My take is that if disabling PMTU causes a significant TCP
throughput reduction over a fast LAN, that's a performance bug in
NetBSD's TCP.  Others may disagree though -- perhaps strongly :).

Do you also have bigger-than-Ethernet media on the NetBSD machine
in question?


>Am I right to conclude that it is safe or at least reasonable to have
>PMTU disc. switched on for a server not directly behind such a
>blackhole? How about clients behind such a blackhole? Will they be
>blocked?

Its reasonable. But without blackhole discovery, traffic to such
clients would still be blocked.

The concern is a relatively naive user behind a misconfigured firewall
who tries to install NetBSD over the net, fails (due to their PMTU
blackhole), then tries something else (FreeBSD, Linux, ...)  which
doesnt turn on PMTU on install media. Too easy to blame NetBSD.

My own (very conservative) take is we really shouldn't ship with PMTU
turned on by default, until we ship robust, working blackhole
discovery which is also on by default.  Not my call, though.

Did all the TCP_NODELAY issues get resolved?