Path: utzoo!attcan!uunet!husc6!rutgers!ucsd!nosc!helios.ee.lbl.gov!lace.lbl.gov!dagg
From: dagg@lace.lbl.gov (Darren Griffiths)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Multiple TCP/IP servers on one host
Message-ID: <957@helios.ee.lbl.gov>
Date: 8 Sep 88 02:46:08 GMT
References: <8809080134.AA05073@ucbvax.Berkeley.EDU>
Sender: usenet@helios.ee.lbl.gov
Reply-To: dagg@lbl.gov (Darren Griffiths)
Organization: Lawrence Berkeley Laboratory
Lines: 49

In article <8809080134.AA05073@ucbvax.Berkeley.EDU> dcrocker@TWG.COM (Dave Crocker) writes:
>There seems to be some convergence on the use of the domain name service
>ip address list, as a means of accessing multiple interfaces (with one 
>interface per milking machine) to the same service host.  A couple of
>notes, however, have mentioned reliance on a feature that is not
>supported:  having the domain name service select which ip address to 
>give you, thereby having the DNS do the randomization necessary to give
>load-leveling.
>
>Selection of the "correct" IP address must be done by the client (e.g.,
>telnet).  The DNS has no way of knowing what use you will put the information
>to and it has no way of distinguishing multiple milking machines from
>multiple connections to different parts (i.e., different networks) on
>an internet.


I have missed some of the recent discussions on this list, so I haven't seen 
any of the previous messages you are referring to, but it sounds like you are
talking about something similar to one of my pet nags about routing (I know 
there are a lot of different nags about routing, but this is my favorite).  In 
many cases there are different paths to the same host, either via backup 
redundant links or because of longer hops through the network.  Usually the 
gateways know about these different paths and take the fastest (determined by 
the metric) and leave the other path untouched.  This other path may be idle 
and quite useful, there are two ways of making use of this path.  

  1)  If the second path was 25% of the speed of the first path then 25% of
      the packets could be sent that way.  This would likely mean that 
      packets would be arriving in different orders than they were sent but
      if the two end sides were running the Van Jacobsen/Mike Karels code
      I believe this wouldn't be to much of a problem.  If they weren't running
      this code you may lose more than you gain due to retransmits.

  2)  The second thing that can be done is a little nicer.  The gateways could  
      look in to the tcp packets and send some of the stuff through one route
      and some through another.  For example, SMTP connections do not always
      need to be taking up bandwidth on a high speed link when they could be
      using a slower backup link leaving the high speed connections for 
      interactive users.  Real people tend to be a lot more impatient than
      computers (although real people are also a lot slower at many things.)

  Cheers,
    --darren


-------------------------------------------------------------------------------
Darren Griffiths                                          DAGG@LBL.GOV
Lawrence Berkeley Labs
Information and Computing Sciences Division