Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!gatech!rutgers!ucla-cs!admin.cognet.ucla.edu!casey From: casey@admin.cognet.ucla.edu (Casey Leedom) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple TCP/IP servers on one host Message-ID: <16103@shemp.CS.UCLA.EDU> Date: 21 Sep 88 10:54:12 GMT References: <8809151736.AA01161@fji.isi.edu> <985@helios.ee.lbl.gov> Sender: news@CS.UCLA.EDU Reply-To: casey@cs.ucla.edu (Casey Leedom) Organization: UCLA Lines: 33 In article <985@helios.ee.lbl.gov> dagg@lbl.gov (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 [128.115.1.1], [26.3.0.21] to the LLNL PSN [26.X.0.21] and a 56Kbps line from labnet-gw.llnl.gov [128.115.3.1], [26.6.0.21] 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. Casey