[25835] in North American Network Operators' Group
Re: should TCPs do MTU black hole detection?
daemon@ATHENA.MIT.EDU (Alex P. Rudnev)
Thu Nov 18 18:45:49 1999
Date: Fri, 19 Nov 1999 02:25:26 +0300 (MSK)
From: "Alex P. Rudnev" <alex@virgin.relcom.eu.net>
To: Vern Paxson <vern@ee.lbl.gov>
Cc: nanog@merit.edu
In-Reply-To: <199911182240.OAA26301@daffy.ee.lbl.gov>
Message-ID: <Pine.SUN.4.10.9911190222480.29219-100000@virgin.relcom.eu.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
Unfortunately, the MTU problem can be caused by the client's network admin as
well as by the ISP; it's very difficult to explain what's wrong, for this
admins, and MTU discovery is not the part of traditional IP approach. This means
that black-hole detection whould be implemented anyway to prevent lost of
connectivity which we have sometimes nopw when some MS-based server or
crlient refuse to allow ip fragmentation.
On Thu, 18 Nov 1999, Vern Paxson wrote:
> Date: Thu, 18 Nov 1999 14:40:01 PST
> From: Vern Paxson <vern@ee.lbl.gov>
> To: nanog@merit.edu
> Subject: should TCPs do MTU black hole detection?
>
>
> The IETF's tcp-impl (TCP implementation) working group has a draft document
> discussing problems with path MTU discovery:
>
> http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-pmtud-02.txt
>
> The main issue we're trying to decide is whether the draft should advocate
> "black hole detection". That is, when a TCP is doing PMTU discovery, but
> somewhere the necessary ICMPs are either not being generated or are being
> filtered out before the TCP receives them, the TCP notices that it's losing
> multiple packets of the same size, so it then tries sending smaller segments,
> even though it hasn't received a "Datagram Too Big" ICMP.
>
> The plus of black hole detection is that it can work around a sometimes very
> hard to debug problem. The minus is that it masks problems that should
> instead be fixed.
>
> To help resolve this issue, I'm wondering whether the ISP community has a
> clear preference for either yes-do-detection or no-we-want-the-problems-fixed.
> Comments appreciated.
>
> Thanks,
>
> Vern
>
>
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
