Casey Leedom (admin.cognet.ucla.edu!casey@CS.UCLA.EDU)
21 Sep 88 10:54:12 GMT
In article <firstname.lastname@example.org> email@example.com (Darren Griffiths) writes:
> Another possible thing to do would be to try and figure out which link is
> the fastest, if it has one line that is 25% the speed of a second line
> then the router could simply send 25% of the packets down the slow
> connection and the rest along the fast connection (perhaps using a random
> number to see which line the packet is going to go along.) I seem to
> remember that someone wrote a paper on this but I can't remember who of
> the top of my head.
Be careful. You're making assumptions about the topology of the
redundant paths to your destination. What happens if the redundant paths
merge at some gateway down the line that is a constriction?
As an example, at Lawrence Livermore National Laboratory there's a
9600bps line from lll-crg.llnl.gov [220.127.116.11], [18.104.22.168] to the LLNL
PSN [26.X.0.21] and a 56Kbps line from labnet-gw.llnl.gov [22.214.171.124],
[126.96.36.199] to the PSN. Labnet-gw is on the LLNL Open LabNet and is
accessible at essentially ethernet speeds. The 9600bps line is a relic
from the bad old days when lll-crg was the LabNet gateway; it's scheduled
for DQing [finally] in a little bit.
Maybe your argument is correct and the flow would sync around the
throughput available through the ``higher speed'' channel, but I'm not
convinced that the two flows bottling up at the PSN wouldn't develop the
equivalent of turbulence. I'd have to see the numbers. Maybe Van could
say something about this.
At the very least, since the bottleneck is really the PSN which is
attached to other PSNs with 56Kbps trunks, labnet-gw is fully capable of
driving the PSN at maximum. Any additional flow coming from the 9600bps
is just going to increase the queue lengths unless the PSN does the same
kind of load balancing with any available redundant PSN-PSN paths.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:30 GMT