Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!LOUIE.UDEL.EDU!Mills
From: Mills@LOUIE.UDEL.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Analyzing Acknowledgement Strategies
Message-ID: <8701131322.a009629@Huey.UDEL.EDU>
Date: Tue, 13-Jan-87 13:22:46 EST
Article-I.D.: Huey.8701131322.a009629
Posted: Tue Jan 13 13:22:46 1987
Date-Received: Tue, 13-Jan-87 19:39:43 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 35
Approved: tcp-ip@sri-nic.arpa

Van,

You are doing some fantastically wonderful stuff that should have been done
long ago. Your conclusions coincide closely to my observations and probably
many others, especially with respect to bunching (aka spasms), especially
with Unix systems using humungus windows over lossy paths. One thing was
not clear from your note. Did your simulations include the use of the Nagle
Algorithm?

Some years ago when I was experimenting along with others on TCP models
I built a flow estimator into the code which produced in effect your
dN/dt. It was designed to produce exactly the result you describe -
spreading the packets uniformly over time. I also intended to build an
estimator for dL/dt as the loss rate (did I get your nomenclature backwards?),
but something else distracted me. However, I did wire up a couple of D/A
converters to panel meters on my desk so I could see the estimators in action.
One was the SRTT and the other the dN/dt. Boy, did I get an eyeful watching
these gizmos in action as tings clogged and unclogged. If there weren't so
many other beasties squealing for attention, I'd like to dive back in those
issues again. The results might well have a profound effect on second-generation
ISO transport protocol implementations.

Idea: Use median-filter estimators instead of linear, recursive-filter ones.
I found the former extraordinarily effective for comparing clocks across the
swamps, which means they should work well for SRTT as well. My variant, which
doesn't have a proper name, is as follows: save the last n RTT samples and
sort them. Identify the median (dither if you have to if the number of samples
is even), then toss out the extremum furthest from the median. Repeat until
only a single sample is left. Season for the endgames. Serve with appropriate
timeout, so that really old info is discarded. I have been using sample windows
of eight.

Keep up the good work.

Dave