Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!FLASH.BELLCORE.COM!karn
From: karn@FLASH.BELLCORE.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  ICMP messages
Message-ID: <8702232051.AA15610@flash.bellcore.com>
Date: Mon, 23-Feb-87 15:51:57 EST
Article-I.D.: flash.8702232051.AA15610
Posted: Mon Feb 23 15:51:57 1987
Date-Received: Thu, 26-Feb-87 22:19:34 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 23
Approved: tcp-ip@sri-nic.arpa

As further argument in favor of my position that TCP should not give up
unless the user process requests it, I have lately been deluged with
complains from users that they and their correspondents are being flooded
with duplicate but incomplete mail messages. It seems that frequently the
net path is just good enough to get a SMTP connection going, but when it
gets to the body of the message, good old Berkeley TCP quickly gives up in
disgust. A half hour later the mailer tries again, ad nauseum. Not only does
this put lots of garbage into people's mailboxes, it wastes net resources
and contributes to congestion collapse.

There is no facility that I know of in our mail system for filtering out
duplicate mail messages, but I don't believe one should really be necessary;
TCP should just be more patient.

I perceive that part of the problem is the fact that many (if not most)
TCP/IP vendors are not the Internet, so they never encounter these problems
on their own.  I would like to make a radical policy suggestion: being a
TCP/IP vendor should be sufficient cause by itself to justify a connection
to the Internet (preferably through a slow and expensive X.25 connection
that THEY have to pay for). The payback in "clean" implementations for the
rest of us will be more than worth it.

Phil