Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!isi.edu!braden
From: braden@isi.edu (Bob Braden)
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Setting Initial Round-trip time
Message-ID: <8610302111.AA04782@braden.isi.edu>
Date: Thu, 30-Oct-86 16:11:09 EST
Article-I.D.: braden.8610302111.AA04782
Posted: Thu Oct 30 16:11:09 1986
Date-Received: Fri, 31-Oct-86 13:28:50 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 39
Approved: tcp-ip@sri-nic.arpa


Members of the END2END taskforce have also been worrying  about your
problem  (setting an initial round-trip time).  It is an important
(but not usually critical) problem for connection-oriented protocols like
TCP and RDP; it is more important and more difficult for a transaction-
oriented transport protocol of the sort we have been stalking.

As Vint says, a background process to gather data is a VERY bad idea.
Nor do I think the hop count is at all useful as a predictor.

However, it may not be a bad idea to maintain a cache of historical data
about observed round trip times to hosts you have talked to recently.
This may help in the case of a small "working set" of hosts you talk to.
In the opposite case ... short transfers to a very large collection of
randomly chosen hosts -- the answer may very well be that you cannot
reasonably expect very good performance when nets are lossy, and should
not waste time trying to obtain the impossible.  And at system startup, 
before there is any historical data, you cannot do very well.

Someone needs to think a little about the right way to maintain such a
cache of historical RTT's per host, with respect to the way you maintain
it (considering dispersion of observations), and how you use the data.

Someone is going to say "You have to ask the gateways".  Well, maybe, but
that would seem to come some time after we are able to provide effective
type-of-service routing over widely-diverse paths.  Or maybe at the
same time?  Still, it wouldn't hurt for us to pose this requirement 
(an ICMP message from a host inquiring about the probable delays to a given
Internet host) to Dave Mills' INARCH task force, and see what they can
come up with.  This requirement seems to go deep into the overall routing
architecture of the Internet.

Finally, our Internet Architect has a simple answer to your problem:
don't use RDP, use NETBLT.  NETBLT shares the principal advantages of
RDP (packet-orientation and selective retransmission), but uses a 
different use of timers so that the RTT is not important.  Of course,
NETBLT has its own set of hard timer problems...

Bob Braden