[52] in Release_7.7_team
AFS 3.3beta
daemon@ATHENA.MIT.EDU (Richard Basch)
Fri Apr 8 17:14:56 1994
Date: Fri, 8 Apr 1994 17:14:32 -0400
To: op@MIT.EDU, network@MIT.EDU, release-77@MIT.EDU
Cc: tytso@MIT.EDU, tjm@MIT.EDU, miki@MIT.EDU, vrt@MIT.EDU
From: "Richard Basch" <basch@MIT.EDU>
AFS 3.3beta has adopted some adaptive algorithms into RX, and though
this is already integrated by Release Engineering into our tree, AFS 3.3
should be considered.
Simple reason: AFS 3.3 includes slow-start (a prime factor in preventing
network meltdowns with adaptive algorithms, like the 1986 BSD 4.3
release Internet meltdown -- see VanJacobsen's papers for details).
Admittedly, this won't have the high use that TCP has, and not quite at
the same scale as the Internet but the potential for collapse does exist
in a large environment, such as ours, where the servers are being bogged
down for processing the RX queues (we now have a user process handling
the stream connection and the extra context handling that the server
process does means that the scale needed for collapse is less).
The client-side can be ready in about a week of effort (and during
testing, I can do a full review of changes since our last client to see
if Transarc has done anything grossly negligent or harmful in this
release; this is something I tend to do before any new release
inclusion, but this was not done with 3.3beta before inclusion into the
release).
Recommendation: since both releases are UNTESTED and NOT VERIFIED, we
should strive for the one that is more network friendly, especially with
the advent of ResNet, we need any congestion control we can get, and not
introduce more problems with less stable network flow algorithms.
-Richard
