hollandm@prlhp1.prl.philips.co.uk (Martin Holland) (08/21/88)
I have an 8 port Micom TCP/IP terminal server with all ports set to slave mode connected to a non-TCP/IP host. This setup allows TCP/IP hosts access to a non TCP/IP host over Ethernet. I now need to add more ports, and intend buying another 8 port server to add to the first. Now the problem. The first server is accessed by name and all the ports are treated as a "hunting group". How can I add a second server without giving it a different name and internet number so the user will not have to try each server in turn to find a vacant port? Is there any way, transparent to the user, that he can "TELNET server1" and if the first server is all in use automatically "TELNET server2"? Martin Holland.
brescia@PARK-STREET.BBN.COM (Mike Brescia) (08/28/88)
How can I add a second server without giving it a different name and
internet number so the user will not have to try each server in turn to
find a vacant port?
I could imagine designing a solution based on the fact that the MICOMs are
connected on an ethernet, and they could cooperate, using the same IP address
(and, by the way, the same ethernet address, preferably a 'multicast' one).
Address recognition in a particular one of the boxes would have to include
the IP protocol (TCP), and the TCP port (corresponding to the terminal port.)
I know of no such design being implemented, nor how you would invent one that
would work on a non-promiscuous net.
Perhaps you can trade your box in for one with more ports.
Good hunting,
Mikekeith@tarantula.spider.co.UK (Keith Mitchell) (08/31/88)
In <605@prlhp1.prl.philips.co.uk>, Martin Holland raises the issue of how to get several terminal servers acting in "milking machine" mode to the same host, to appear as one to other nodes on the network. I could suggest upgrading to a SpiderPort, which has 10 lines to the NTS100's 8, but I don't think this is really a terribly helpful solution. This is an interesting problem, and while there are a number of possible approaches to solving which fit in with the TCP/IP archectiture, none are completely satisfactory, particularly if the requirement is for a scheme which is transparent to the incoming (Telnet client) caller. One approach could be to use the Telnet Reconnection option (NIC 15391). Here the connection would be established to a Telnet server which knows when all the ports on one server were full, and could then tell the client to try connecting to a different server on another Internet address. However, this requires the Reconnection option to be implemented on all possible clients. Since I have never heard of any implementations of this with TCP, I suspect this approach is a non-starter. Has anyone used the Telnet Reconnection option over TCP for this sort of thing anywhere ? There is also an issue here of who does the redirect - should there be a central server which everybody connects to intially, and which keeps track of everyone's resources so it knows where to redirect to, or should one server simply redirect to another when it knows it is full ? The issue of who knows what ports are free is something which generally needs to be addressed for various schemes like this. For example, the ARP-based scheme proposed by Mike Brescia <brescia@park-street.bbn.com>. Another way is to fudge name lookup in some way. If a name server could be got at, it could return a different address in response to the same user string depending on how loaded the telnet servers are. This is not very nice as it blurs functional boundaries between name servers, and what one could call "resource location servers". This suggests another approach, where the client sends a request out to find out what server(s) have free ports, and uses the information returned to decide who to actually connect to (cf BOOTP). Resource Location Protocol (RFC 887) might be a possibility here. A cleaner scheme for exploiting the name lookup mechanism as a solution is to have an alias-on-fail arrangement. For example if a given hostname fails, prepend a "&" and try again. The host table would then look something like: spport1 192.35.138.1 &spport1 192.35.138.2 spport2 192.35.138.3 The disadvantages with this are again it requires non-standard client software, and the cumulative time-out delay could get quite large towards the end of the list (eg. &&&spport1 ). Clearly with all these schemes there is a trade-off between cleanness of approach, and how transparent it is to existing hosts. If one approach could be standardised on as best, then I think some progress towards solving this problem might be made. Keith Mitchell Spider Systems Ltd. keith@spider.co.uk 65 Bonnington Road keith%spider@uk.ac.hw.cs Edinburgh, Scotland keith%spider.co.uk@uunet.uu.net +44 31-554 9424 ...!uunet!ukc!spider!keith
dcrocker@TWG.COM (Dave Crocker) (08/31/88)
You have a basic question to ask: Is the solution to your problem constrained
to use existing mechanisms or do you have freedom to implement additional
capabilities? If you must use only existing products, then you are unlikely
to find a solution.
In general, Keith Mitchell's set of alternative is reasonable, if you
can build your own mechanisms. (There are some interesting problems
involved with having the different milking machines know about each other
and each other's availability, but most of this is surmountable.)
Probably the minimum amount of effort -- even having a minute chance of
working without any development -- is to use the ability of the Domain
Name Service to list multiple addresses for a host. Here's how it goes:
1. For management purposes, list each milking machine by a unique name.
Then, you can access specific ones, when you need to.
2. Choose a generic name, under which you list all of the milking machines'
addresses.
3. When you need to do an access, use the generic name to do a DNS lookup
and get the list of addresses.
4. Choose an address from the list. If you want to attemp load-leveling,
throw a random number, to select the first address.
(Sorry, but true, empirically-derived load-leveling does not work
without all of the inter-milking machine communication mentioned above.)
5. Pray that the milking machine product sends a reasonable rejection when
all of its lines are full.
6. When receiving such an error, try the next address.
The reason that you may be able to use this scheme without software development
is that there may be some telnet implementations out there that do step 6
already. Unfortunately, I doubt it.
Dave Crocker
The Wollongong Groupkwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (08/31/88)
In article <16115.8808301546@brahma.cs.hw.ac.uk> > keith@tarantula.spider.co.UK (Keith Mitchell) writes: > >In <605@prlhp1.prl.philips.co.uk>, Martin Holland raises the issue of how >to get several terminal servers acting in "milking machine" mode to the same >host, to appear as one to other nodes on the network. > There are actually two problems: How to assign multiple rotaries (telco terminology) to one box and how to assign multiple boxes to one rotary. It seems to me the solutions to both problems are related and require particular capabilities of both client and host server telnet implementations. >This is an interesting problem, and while there are a number of possible >approaches to solving which fit in with the TCP/IP archectiture, none are >completely satisfactory, particularly if the requirement is for a scheme >which is transparent to the incoming (Telnet client) caller. > Seems to me that name server lookup can handle this transparently, so long as the resolver in the client telnet takes reasonable actions on the response received. > >Another way is to fudge name lookup in some way. If a name server could be >got at, it could return a different address in response to the same user >string depending on how loaded the telnet servers are. This is the same situation as a multi-homed host and I believe the name server is set up to handle this with multiple records for a single host. Just substitute the concept of "multi-box rotary" for "multi-homed host". Name servers return all addresses listed for a given name. The resolver on the telnet client would need to be smart enough to try all returned names before giving up on the connection request. So the problem becomes one for the client (ie terminal) server and not the host (ie, milking machine) server. If the client server simply tries the first address returned and drops others, then this approach fails. The other situation is different. The host server must be able to associate a subset of its ports to one IP address, possibly down to one IP address per port. Then the client telnet requests service by name and receives either the single IP address that the host server will associate to, say, three serial ports, or it receives three separate responses corresponding to the three separate ports of that rotary. In the first case, the client only has to try one connection and the host server handles port contention itself. The second case is the same as the multi-box rotary problem above and the client server must be able to try multiple addresses in sequence before aborting the attempt and reporting back to the user. So it seems to me that the solution is partly in client telnet (try all addresses in sequence) and partly in the host telnet (associate one or more ports to one IP address for efficiency). Kent England, Boston University
casey@admin.cognet.ucla.edu (Casey Leedom) (09/01/88)
In article <24663@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: > Seems to me that name server lookup can handle this > transparently, so long as the resolver in the client telnet takes > reasonable actions on the response received. > > This is the same situation as a multi-homed host and I believe > the name server is set up to handle this with multiple records for a > single host. Name servers return all addresses listed for a given name. > The ... telnet client would need to be smart enough to try all returned > names before giving up on the connection request. 4.3BSD and later telnet does this (99% assurance - I'd look, to verify this absolutely, but my ARPANET connection has gone down). If you simply do the equivalent of: a.b.c.d terminal-server r.s.t.u terminal-server and then do "telnet terminal-server", you get the correct response. If your telnet client doesn't do this, you can grab the latest telnet client sources from ucbarpa (again this is an "I believe - I hate it when I can't check things). Casey
RAF@NIHCU.BITNET ("Roger Fajman") (09/02/88)
I'd just like to say that multiple terminal servers on one host will be a problem for us too. Right now we have a host that has about 700 async dial ports. We expect that network access will begin to supplant modem access in the near future, as we get our network connections in gear. Even a cisco ASM with 96 ports (the biggest terminal server that I know of) wouldn't be enough. Even if it were compatible with our host, which it isn't. The solution using the domain name system sounds best because it doesn't require changing all the Telnet implementations on the Internet. If the choosing is done in the name server (which seems necessary to avoid changing all the Telnets), then it is necessary to set the time to live to a small value, so that the random response won't be cached and reused many times. This increases the number of name server requests, but nothing is perfect.
dcrocker@TWG.COM (Dave Crocker) (09/07/88)
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. Dave
dagg@lace.lbl.gov (Darren Griffiths) (09/08/88)
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
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (09/09/88)
In article <957@helios.ee.lbl.gov> dagg@lbl.gov (Darren Griffiths) writes: > >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. > When you say "different paths" do you mean alternate routes to the same address or alternate addresses to the same host (which is the subject of the thread)? In the first case, you as a user don't care what paths your datagrams take so long as they get there quickly. However, load sharing is done by ciscoIGRP and is proposed in Moy's Open SPF IGP protocol draft for equal-cost routes. Presumably, the untouched routes are being used by other datagram streams. If you mean alternate addresses to the same host, that won't work for a telnet stream, will it? How would a router know anything about relationships between IP addresses? > 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.) > One set of warnings: "stateful routers" and "router crash". But what you are suggesting could be a Type of Service kind of thing. Better than having the router decide, the application can tell the router about what it wants in the way of security, delay, bandwidth, etc. Kent England, BU
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (09/12/88)
W.r.t. the discussion on having domain servers randomize addresses for the purpose of load balancing, note that the domain system delegation feature can be used to good effect. Authority for single hosts can be delegated as easily as for groups of them. It would be easy to write a specialized nameserver-like program that could randomly select one of a group of addresses. For that matter, such a gadget could even check with the terminal servers (or whatever resources) directly and choose one known to be available. It could be far simpler than a full-fledged name server, just capable of parsing queries, constructing replies to the ones it knew about and ignoring the rest. Stuart
dnwcv@dcatla.UUCP (William C. VerSteeg) (09/12/88)
Many ways have been discussed to make a mapping between one logical name and many IP addresses. These schemes all rely on having a machine resolve a name every time it wishes to open a circuit. Most implementations have caches, do they not? It seems that for this to work, a resolver would need to tell a client "don't cache this response". Then the next time a circuit was established, the resolver would be able to look at the available resources and determine which IP address to return. Don't get me wrong, I don't think we should really do this, but if one wanted to have total control over resource allocation, caching techniques would have to be considered. Bill VerSteeg
cire@CLASH.CISCO.COM (09/13/88)
Having a domain server randomize the responses for a given host strikes me as something of a round about way of achieving the desired solution. Certainly it will work. However it seems to be extending the Domain System in ways it was not intended to go. I realize there is a desire to use existing protocols and applications with minimum modifications. However, perhaps the suggested methods are not the way to go. Has anyone experimented with load balancing protocols? -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941
rogerh@arizona.edu (Roger Hayes) (09/14/88)
In article <957@helios.ee.lbl.gov> dagg@lbl.gov (Darren Griffiths) writes: >[...] In >many cases there are different paths to the same host, [...] >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. [...] > if the two end sides were running the Van Jacobsen/Mike Karels code > I believe this wouldn't be to much of a problem. [...] > > 2) The second thing that can be done is a little nicer. [...] The first thing (splitting load among routes) would screw up the Jacobson/Karels improved TCP completely. They get a big win by estimating the variance of the round trip time; using alternating routes for different packets would drive this variance way up, causing the timeout to be set high, causing long stoppages on lost packets. Further, their code for calculating optimum window size, which is pretty subtle, tests for increased available bandwidth by increasing window size. I can imagine that this code would get pretty thoroughly confused if the period of route-switching was near the window size, as that would cause successive windows to have wildly varying proportions of samples from the two routes. The slower route would periodically be heavily overloaded (when the outstanding packets in the window happened to mostly be sent via the slow route) while the faster route would operate below its optimal point. Seems like the best way to make use of alternate routes is by implementing the type-of-service stuff. Roger Hayes rogerh@arizona.edu
prue@VENERA.ISI.EDU (09/16/88)
>> 1) If the second path was 25% of the speed of the first path then 25% of >> the packets could be sent that way. [...] >> if the two end sides were running the Van Jacobsen/Mike Karels code >> I believe this wouldn't be to much of a problem. [...] > > >The first thing (splitting load among routes) would screw up the >Jacobson/Karels improved TCP completely. They get a big win by >estimating the variance of the round trip time; using alternating >routes for different packets would drive this variance way up, causing >the timeout to be set high, causing long stoppages on lost packets. I disagree. The first path is four times as fast but has four times as many packets. The link delay is only 1/4 the second line but the queuing delay is four times as great. The variation of the delivery times for the five packets would be less than using a single line. As the queue sizes go up the variation in the network delay goes up. I do however agree with your other point, type of service routing could put the second path to very good use. Requards, Walt Prue Prue@isi.edu
dagg@lace.lbl.gov (Darren Griffiths) (09/21/88)
In article <8809151736.AA01161@fji.isi.edu> prue@VENERA.ISI.EDU writes: >>> 1) If the second path was 25% of the speed of the first path then 25% of >>> the packets could be sent that way. [...] >>> if the two end sides were running the Van Jacobsen/Mike Karels code >>> I believe this wouldn't be to much of a problem. [...] >> >> >>The first thing (splitting load among routes) would screw up the >>Jacobson/Karels improved TCP completely. They get a big win by >>estimating the variance of the round trip time; using alternating >>routes for different packets would drive this variance way up, causing >>the timeout to be set high, causing long stoppages on lost packets. > >I disagree. The first path is four times as fast but has four times as >many packets. The link delay is only 1/4 the second line but the queuing >delay is four times as great. The variation of the delivery times for the >five packets would be less than using a single line. As the queue sizes go >up the variation in the network delay goes up. > >I do however agree with your other point, type of service routing could >put the second path to very good use. The first time I thought out loud about routing through two different paths I did mention that it may mess up the van/mike tcp code. Fortunately this was at the SIGcomm conference in Stanford and Van wasn't far away. He quickly set me straight and with a little extra thought it is fairly obvious that the code would stabalize around the acks of the faster line. A couple of people have mentioned that instead of looking for well known ports to decide whether to use a fast line or not that the TOS field should be used. I agree, this would be much better, but I decided to watch a couple of packets go by on the local LBL net. I didn't look to long, but I found very few things actually touch that field. 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. It would be interesting to try different routing algorithms and see which is the more efficient, with efficient be defined by the perceived throughput to the user as well as the number of packets going through. I can think of a few methods that could be tried: 1 - Leave things the way they are, and just taking the fastest path. 2 - Choose the path depending on the TOS field, and hope someone uses it. 3 - Choose the path based on the port (TELNETs go the fast way, SMTP goes the slow way.) 4 - Send a percentage of the packets down one path and the rest down another. Can anyone think of any others? Perhaps when I have some free time I'll do a couple of tests and see what I come up with. Cheers, --darren ------------------------------------------------------------------------------- Darren Griffiths DAGG@LBL.GOV Lawrence Berkeley Labs Information and Computing Sciences Division
casey@admin.cognet.ucla.edu (Casey Leedom) (09/21/88)
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
BILLW@MATHOM.CISCO.COM (William Westfield) (09/22/88)
Routers from cisco Systems have supported load balancing among equivalent routes for a long time by round robining the packets among routes. We also support a "variance" command for specifying a multiplier that may be applied to consider routes for load sharing. A variance of 1 implies that we use only the best route, a variance of 4 implies that we use the best route, and any other routes up to 4 times as bad as the best route. A route 4 times as bad as the best route will get 1/4 of the packets... This works just fine for relatively simple networks, but for very large networks, there is not enough resolution in routing metrics, and you tend to use routes that you really wish you hadn't for distant hosts (this is true even with cisco's IGRP, which has considerably better resolution than any other routing protocol). It still seems to work for relatively small variance values (say, <4). (What it boils down to is that it is probably reasonable to use a 200 mS path instead of a 50 mS path, but not to use a 16 S path instead of a 4 S path.) Setting the variance to greater than 1 is also a good way to find bugs in reassembly algorithms, as packets WILL arrive in a different order than they were sent. This will not allow a host to pick between several gateways on an ethernet (it only allows a gateway to pick between several paths). But current wisdom is that hosts should not know anything about the internals of routing issues anyway. Bill Westfield cisco Systems. -------