[4579] in Athena Bugs

home help back first fref pref prev next nref lref last post

Re: AFS and living groups

daemon@ATHENA.MIT.EDU (Bill Sommerfeld)
Tue Mar 20 23:34:30 1990

Date: Tue, 20 Mar 90 23:34:10 -0500
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU
In-Reply-To: [4568] in bugs
This is a known problem with RX.  For reasonable performance over
high-throughput, high-latency paths, it uses a 16-packet window, which
is wide open when starting after a pause; the result is that it fires
off 16 maximum-size packets back-to-back, with little or no
inter-packet spacing; it also uses a default timeout of 2 seconds,
after which it starts retransmitting.

At 14.4KBaud, 16*1.5KBytes=16*12Kbits=~13 seconds.  

If we care about the slow-speed links, someone (the mythical software
engineer with free time on his hands) needs to go in and
Van-Jacobsonize RX, adding slow start and the like.  Transarc is
unlikely to do this because they're eventually going to be throwing RX
away in favor of NCS, which, by the time they get to it, should be
Jacobsenized.  (note: "this is not a product commitment; this is just
a rumor")

This would also likely improve its behavior on fast clients, which
send packets too fast for the gateways to keep up.

Adding slow-start and the like to RX shouldn't take a competant hacker
more than a man-week or two; anyone who wants to do it should read
Van's paper first.

Note however that Steve Dyer has been using AFS over 9.6KB links
without seeing the same sorts of problems, although a) he's using it
on an RT, and b) I think the SLIP line is connected directly to his
AFS client, so it has a better chance of knowing when to "hold back"..

Someone want to write up a project proposal on this?

					- Bill

home help back first fref pref prev next nref lref last post