Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!BRL.ARPA!mike
From: mike@BRL.ARPA.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  ICMP messages
Message-ID: <8702191948.aa19638@SEM.BRL.ARPA>
Date: Thu, 19-Feb-87 19:48:00 EST
Article-I.D.: SEM.8702191948.aa19638
Posted: Thu Feb 19 19:48:00 1987
Date-Received: Sat, 21-Feb-87 10:47:03 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 21
Approved: tcp-ip@sri-nic.arpa

The idea about having mailers stick around and let TCP go "forever"
to get mail though may be OK if you don't send much mail, but some
of our machines find themselves having to deliver mail to >> 5,000
host/message destinations per day.  It takes us several mailer
daemons running in parallel to punch this much mail through.
Without application level timeouts, talking to dead or overrun hosts
could tie up a significant fraction of our transmission daemon
resources.  Not all mail systems even offer the option of having multiple
transmission daemons, and instead rely on a single daemon for all
mail sending operations.

Clearly, application level timeouts need to be set to reasonable
values.  However, our experience with operating many mail-intensive
machines has been that SMTP servers, even in 1987, have many failure
modes.  SMTP servers can fail to answer after any part of the
transaction, even though their host and TCP connections are still well.
This level of failure can only be dealt with by application level timeouts.

Just as security can only be dealt with across all protocol levels,
the issue of timeouts spans protocol levels as well.
	-Mike