[ On Fri, November 20, 1998 at 13:58:28 (-0800), Marc Slemko wrote: ]
> Subject: Re: SOLVED!  The cause of puzzling TCP (eg. WHOIS) connection failures  with some InterNIC.net hosts
>
> I thought you had said that there were no differences in the traffic
> dumps between working and non-working connections...

For the benefit of tech-net readers who are not on NANOG:

I think what I had said was "that there were no differences in the
tcpdump traces between working and non-working connections *except* the
initial window size negotiated".  The other difference was that in my
initial investigations I'd failed to notice the DF bit and the fact that
the there was an ICMP unreachable "needs frag" reply being sent by the
router.

To be more specific about my suggestion:

I do think it would be more friendly for a NetBSD router to optionally
ignore the "DF" bit if the same oversize packet is re-transmitted even
after the ICMP "needs frag" reply has been sent, perhaps after "N"
retransmissions where "N" is calculated based on some magical formula
that uses the packet size and the delay between retransmissions in order
to guess at how long it would take the ICMP reply to get back to the
originator and for a smaller packet to arrive.

Administrators of NetBSD based gateways using <1500 byte MTUs could then
enable such behaviour in order to avoid connection failures with badly
behaved hosts that use DF when they don't really mean to do path MTU
discovery and stupidly configured firewalls that cause PMTU-D to fail
because they filter out ICMP informational messages.  (I.e. put the real
intentions of "The Robustness Principle" in action!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>