Date: Fri, 9 Feb 1996 00:00:05 +0000 (GMT) From: "Adam David" <adam@veda.is> To: wollman@lcs.mit.edu (Garrett A. Wollman) Cc: freebsd-current@freebsd.org Subject: Re: TCP/IP interoperability problem, workaround Message-ID: <199602090000.AAA03653@veda.is> In-Reply-To: <9602082045.AA28752@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Feb 8, 96 03:45:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett has been helping me to understand this problem by discussing it with me in private email. It is time again to post to a wider audience. Garrett> It is caused by a broken gateway anywhere in the path where Garrett> fragmentation would normally be required (i.e., where the MTU Garrett> decreases from one link to the next). That's why you didn't have any Garrett> problems after decreasing the MTU. Okay, that makes good sense. Now, there is a high likelihood of there still being vast numbers of such broken gateways out there... as in the case of slower progress in some regions... and continue to be used within some networks, and on some inter-organisational links at a distance from the main trunkways of the net. For instance, our link to the rest of the world looks like this: *.veda.is branch (ethernet=10Mb/s:mtu=1500) --broken_router-- (V.32bis=19.2kb/s:SLIP=57.6kb/s:mtu=552) --broken_router-- *.is branch (ethernet=10Mb/s:mtu=1500) It looks like we could raise our SLIP MTU to 1500 and lose some latency on the link, or invest in a faster link (and if there are connectivity problems elsewhere, let them be dealt with in their local jurisdiction and their own sweet time)... bearing in mind that FreeBSD might be the only leading system with which such end-to-end connectivity troubles are encountered. Alternatively, it might be sensible to advise the use of -lock -mtu 1500 on outgoing routes, as a commented example in /etc/sysconfig (valid for most machines connected by slow-ethernet and PPP), in order to allow for the widespread existence of broken gateways out there. Or as a third option, might it be possible or even desirable to implement a fallback mechanism whereby if Path MTU Discovery fails due to a non-compliant gateway, another method is used in order to better assure the delivery of outgoing packets? (The previous method worked across links that create a blockage now that the current method is used without a fallback). What do people think about these suggestions? -- Adam David <adam@veda.is>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602090000.AAA03653>