>I was having the same sort of problems with the generic kernel on Jonathan
>Stone's miniroot.  Has anyone else encountered this, or have an idea as to
>what's happening here?  

I've never seen this before.

A brief look at the kernel source shows what's happening must be this:
the TCP retransmit timer is going off, tcp_timers() is being called,
detects that it's backed off its TCP retransmit timer so far that it's
used 1/4 of the maximum retransmission shift amount (the smoothed
round-trip-time gets shifted to give an exponential function), and so
tcp_timers is calling in_losing().  in_losing() marks the RTM_LOSING
flag on the route -- presumably, on your default route.

That's the only place in the kernel where RTM_LOSING gets set.

I'd turn off TCP 1323 large-window processing with sysctl, with
	sysctl -w net.inet.tcp.rfc1323 = 0

in case the NCSA Telnet has a flaky-or-incompatible TCP large windows
(and TCP timestamp) implementation, which is upsetting the NetBSD TCP.
If that doesn't fix things, I'd blame the NCSA telnet stack.

It's hard to do any more without a tcpdump (or equivalent) of the
Telnet session between NCSA Telnet and the NetBSD system.