Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!bellcore!ulysses!ucbvax!USC-ISI.ARPA!CERF
From: CERF@USC-ISI.ARPA
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Adaptive SMTP Timeouts
Message-ID: <[USC-ISI.ARPA]29-May-86.21:28:26.CERF>
Date: Thu, 29-May-86 21:28:00 EDT
Article-I.D.: <[USC-ISI.ARPA]29-May-86.21:28:26.CERF>
Posted: Thu May 29 21:28:00 1986
Date-Received: Sat, 31-May-86 15:45:00 EDT
References: <8605291015.AA16996@sering.uucp>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 22
Approved: tcp-ip@sri-nic.arpa


Doug,

In the complex internet environment, round-trip variations can be significant,
depending on the paths taken, the satellite hops, congestion, various failures,
and so on. Under jamming conditions, bandwidths drop to increase S/N and also
increase delays (unfortunately). At least with respect to DoD objectives,
the system has to work even if its parameters exceed the nominally desired
limits. Consequently, many of us have been reluctant to rely on any fixed
maxima if we can find ways to measure and adapt instead.

I don't disagree that it would be easier to declare some maximum and in some
instances (e.g. the 576 octet IP packet size which all subsystems must carry
without fragmentation) we have done so. But with respect to dynamic parameters
such as round-trip time, we have tried hard not to allow ourselves to be
bequiled by the apparent simplicity of declared limits.

There may well be some other dissenting opinions on this point out there in
the diverse world which makes up this interest group, but I believe I am
stating the principal view of those of us concerned for DoD requirements.

Vint