Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!ucbcad!ucbvax!UDEL.EDU!Mills
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Life after source quench
Message-ID: <8711092241.aa10552@Huey.UDEL.EDU>
Date: Mon, 9-Nov-87 22:41:28 EST
Article-I.D.: Huey.8711092241.aa10552
Posted: Mon Nov  9 22:41:28 1987
Date-Received: Sun, 15-Nov-87 20:46:52 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 19

Charley,

Gee, you didn't say how mungus the packet is - 65K give/take fragments?
An incremental delay of 500 ms is probably okay for the 56-Kbps Backbone
or ARPANET, but certainly not for the ARPANET/MILNET gateways. To do it
right, you should know something more about the path, such as overall
delay, estimated flow rates and loss rates. TCP of course could give
that to you, assuming TCP were involved. I doubt UDP or raw IP would
generate the observed horsepower; on the other hand, a Craycreature
may well be needed to supply the watts for tomorrow's domain-name
server turbines.

If your suggested scenario is correct and the quench needs nick only
one every thirty seconds or so, that would be real swell news. However,
Hans-Werner Braun reports finding quench gushers for the UIUC Craykiller
at other times, which suggests additional testing and observation may
be in order.

Dave