Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!nike!ucbcad!ucbvax!ZERMATT.LCS.MIT.EDU!james
From: james@ZERMATT.LCS.MIT.EDU ("James William O'Toole, Jr.")
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Setting Initial Round-trip time
Message-ID: <861030130016.1.JAMES@GREEN-GRASS.LCS.MIT.EDU>
Date: Thu, 30-Oct-86 13:00:00 EST
Article-I.D.: GREEN-GR.861030130016.1.JAMES
Posted: Thu Oct 30 13:00:00 1986
Date-Received: Fri, 31-Oct-86 02:12:34 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 16
Approved: tcp-ip@sri-nic.arpa


    Date: 30 Oct 1986 04:24-EST
    From: CERF@A.ISI.EDU
    Subject: Re: Setting Initial Round-trip time

    A background process might try to gather data - but this would by like
    pinging everyone just in case you might want to talk with them - leads
    to predictable disaster.

A background process could more easily maintain a cache of round trip
time data measured from recent traffic.  Connections from a given host
are probably concentrated on certain destinations, so you ought to be
able to do much better than pinging.  Of course, you still need to know
which measurements to take and how to use them.  Mean and variance of
round trip time on a per host basis, with recent data more heavily
weighted, perhaps?