Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!FLASH.BELLCORE.COM!karn
From: karn@FLASH.BELLCORE.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: ICMP messages
Message-ID: <8702132020.AA26223@flash.bellcore.com>
Date: Fri, 13-Feb-87 15:20:18 EST
Article-I.D.: flash.8702132020.AA26223
Posted: Fri Feb 13 15:20:18 1987
Date-Received: Sat, 14-Feb-87 15:43:49 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 30
Approved: tcp-ip@sri-nic.arpa

Here are some thoughts based on those of Dave Clark in RFC-816, which I
think is still well worth reading.

When the network breaks, a real-time human user may or may not be involved
(e.g., Telnet vs. a background mail transfer).  In the former case, you
should let the user know what's happening (i.e., show him ICMP messages)
*but* you should leave it up to him as to what to do. If he wants to wait
indefinitely until things get better, he should have that option.

In the case of two computers talking, what's the hurry?  One of the major
virtues of a (properly programmed) computer is patience. If a SMTP session
gets stuck, why not just let TCP keep trying "forever", provided that it
backs off its retransmissions enough to prevent network congestion?  Keep
the ICMP messages around for debugging, but let TCP do its job instead of
giving up and forcing the application to start all over again.  Your mail
daemon is going to be sending out connection requests every hour or so
anyway (not to mention all those MX and IP address domain queries), so why
not just keep sending data packets so you can pick up where things left off?
Only when the remote host crashes and comes back up will you have to start
over.  The only drawback I can see with this is the memory used by the
almost idle mailer, but hey, memory is free these days.

So the solution, I think, is to use ICMP messages for debugging, but don't
let them affect TCP's actions.  One of my pet peeves about many TCP
implementations is how impatient they are, both in retransmission timing and
"give up" timing.  The end result is a network prone to the kind of
congestion collapse John Nagle talked about in his paper on networks with
infinite buffering.  Fix the timers and you'll avoid this.

Phil