Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!SH.CS.NET!craig
From: craig@SH.CS.NET.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Adaptive SMTP Timeouts
Message-ID: <8605282054.AA03405@ucbvax.Berkeley.EDU>
Date: Wed, 28-May-86 17:23:07 EDT
Article-I.D.: ucbvax.8605282054.AA03405
Posted: Wed May 28 17:23:07 1986
Date-Received: Thu, 29-May-86 08:05:58 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26
Approved: tcp-ip@sri-nic.arpa


    I've noticed that a lot of mailers use timeouts on some or
all SMTP commands, to make sure that a defective remote mailer doesn't
cause the other mailer to hang permanently waiting for a reply.  All the
code I have seen uses a fixed timeout period.  For example, you always
have 30 seconds to reply to a HELO, or some such.

    It has occurred to me that it might make more sense for such mailers
to adapt their timeouts to perceived performance at the remote end.
For example, I've seen 10-15 second packet round trip times on parts
of the Internet.  In such a situation, a 30 second timeout is actually
a 15 second timeout for the other mailer.

    One idea for adapting timeouts is to "ping" the other end of the
SMTP link with a NOOP command every so often to find out the round
trip time, and also get some vague sense of the remote machine's
load (since it must actually recognize the NOOP and compose a reply).
Another is to simply do one test at the start of the interaction,
using the HELO command as the benchmark.

    What do other people think of this idea?.  Anyone got other
interesting ways to adjust the timeouts?  We're serioiusly considering
putting this feature into MMDF2b.

Craig Partridge
CSNET Technical Staff