Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!bellcore!faline!karn
From: karn@faline.bellcore.com (Phil R. Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ..."layering violations"
Message-ID: <1505@faline.bellcore.com>
Date: Wed, 28-Oct-87 17:33:04 EST
Article-I.D.: faline.1505
Posted: Wed Oct 28 17:33:04 1987
Date-Received: Sat, 31-Oct-87 13:33:10 EST
References: <276112.871027.JBVB@AI.AI.MIT.EDU>
Organization: Bell Communications Research, Inc
Lines: 31
Summary: There is something to be said for ignoring ICMP unreachables...

> Even something like ICMP illustrates this:  Essentially all TCPs will
> return an error to their caller whenb they receive a Reset.  An ICMP
> Destination Unreachable message implies much the same thing, but many
> TCP/IPs won't return an error to the caller....

There is something to be said for this. ICMP unreachable messages are
often generated under transitory conditions.  Many TCPs (e.g., BSD UNIX)
bomb out when they get an ICMP unreachable message, even if a connection
has already handled many packets successfully. I find this *most*
annoying; TCP is supposed to provide reliable end-to-end communications,
not bomb out at the slightest provocation from the underlying Internet.

There are basically two classes of network applications: interactive
users and automatic daemons.  An interactive network command should always
leave it up to the user to decide whether he or she wants to give up or
be patient and see if the problem goes away. An automatic daemon is much
more patient, so as long as the TCP is careful to avoid wasting network
resources (e.g., by backing off) I see little reason it shouldn't just
keep trying "forever".  ICMP unreachable messages are very useful
debugging tools (or at least they would be if they actually contained
the source address of the complaining gateway instead of some nonsense
IP address like that of the original destination). But they shouldn't
affect TCP's operation without the consent of the user.

Even worse are TCP "keep alive" timers.  Not only do they waste network
resources, as far as I'm concerned they serve no useful purpose at all.
If I have a long-idle TCP connection, why should I care if the path
goes down temporarily? I certainly don't want my connection aborted
because of it.

Phil