minshall@kinetics.UUCP (Greg Minshall) (05/17/88)
This is a very nice and timely discussion for me, given where I am
in some product development cycle.
What my tendancy has been is to allow for the specification of a default
router (yes, just one). If the router isn't specified, then we listen
for RIP broadcasts. Now, I never know what is INSIDE a RIP packet. However,
I choose a default router based on the largest RIP packet seen, and I stay
with that router for five minutes or so. So, if I continue getting RIP
packets, then I keep following routers.
Whenever I receive a host or network ICMP redirect, I update my *HOST* route
(based on the destination IP address which comes along with the ICMP packet).
This host route lives for five minutes or so (maybe 20 minutes). It then
times out, and we use the current default router to send to (the router
may then send back a redirect, which we will believe).
I am very sympathetic to almost all sides of this debate. I strongly believe
that hosts should stay out of the routing game. I strongly *wish* all
hosts had only one interface, but that isn't always desireable.
I also feel for those souls whose routers occasionally crash, and who would
like routes to switch automatically. I don't believe that just because
you need this capability once per day that should exclude it from being
automated.
Right now, listening for RIP packets is, in many environments, the best way
to locate potential gateways. There is no reason this needs to have a
separate process listening - consider these packets to be like ICMP packets.
As a design issue, I think that the ISO scheme seems very well thought out.
I want to be able to hear "I'm a router and I'm alive" packets at a fairly
high rate (at least once per minute).
I tend to lean towards unsolicited broadcasts (multicasts, whatever) from the
routers rather than a "query-response" scheme ("any routers out there?" "here
I am") for a few reasons. First off, there are many more hosts than gateways,
so the unsolicited broadcasts should generate less (broadcast or multicast)
traffic. Second, I'd rather not have to worry about how a uni-directional
UDP stream is supposed to decide that its packets aren't making it to the
other end of the wire. Third, I'm not sure that every time TCP retransmits
a packet I want to have to revalidate the route.
Greg Minshall
Kinetics, Inc. 415-947-0998 ucbvax!mtxinu!kinetics!minshallKASTEN@MITVMA.MIT.EDU (Frank Kastenholz) (05/18/88)
>What my tendancy has been is to allow for the specification of a default >router (yes, just one). If the router isn't specified, then we listen >for RIP broadcasts. Now, I never know what is INSIDE a RIP packet. However, >I choose a default router based on the largest RIP packet seen, and I stay >with that router for five minutes or so. So, if I continue getting RIP >packets, then I keep following routers. This assumes that your host can understand that the packet is a RIP packet. If my routers use another IGP then the hosts will not know that it is an IGP packet so they can not "backtrack" to the source of the packet and get a router. >I also feel for those souls whose routers occasionally crash, and who would >like routes to switch automatically. I don't believe that just because >you need this capability once per day that should exclude it from being >automated. Unfortunately I must strongly disagree with the last sentence. TCP/IP is entering the non-technical world very rapidly. The company that I work for makes large editorial systems for newspapers - lets reporters and ad takers enter their material, editors edit it, layout people design and build the pages and then output the whole thing to a photo typesetter. Newspaper people (reporters/editors/etc) know next to nothing about networking and we can't really teach them. This model is valid in more and more networks. the failure recovery mechanism MUST BE AUTOMATIC. The recovery mechanism is required for a very simple reason - money. If a newspaper doesn't go to press because the network broke then the paper does not realize its advertising revenues - and that is the name of the game for all of the "commercial" TCP/IP sites. I think that the idea of using multicasts/broadcasts is better than the query/response model. It lets the hosts detect a gateway failure before they go through a few retransmissions wasting resources (assuming that the hosts are reasonably intelligent). The only possible problem is that there may be networks with many gateways and the "I am a gateway" traffic could get to be burdensome (especially for small hosts that can't handle many packets per second - e.g. PC's). Perhaps using an Ethernet multicast address (for Ethernet networks) would be the way to go - it could let small hosts filter out the unwanted traffic. If this is done, though, a query/response mechanism may also be needed. Cheers Frank Kastenholz EPPS Inc - a Kodak Company All opinions are mine........
romkey@kaos.UUCP (John Romkey) (05/19/88)
In article <8805161802.AA15658@mtxinu.UUCP> minshall@kinetics.UUCP (Greg Minshall) writes: >Right now, listening for RIP packets is, in many environments, the best way >to locate potential gateways. There is no reason this needs to have a >separate process listening - consider these packets to be like ICMP packets. Many PC's that are out on the Internet right now aren't on the Internet full time. They're running TCP on demand - when user wants to telnet, then they're active on the net and the rest of the time they're deaf dumb and blind. >Third, I'm not sure that every time TCP retransmits a packet I want to >have to revalidate the route. I don't think TCP should revalidate the route every time it retransmits. I think it should when it's decided it's in trouble. Which should be, perhaps, when it's noticed that the round trip delay has been going up steadily or that it's half of the way to deciding the connection is dead. These are just suggestions, I don't have any definite heuristics for it. If I were writing another IP and TCP implementaiton I'd probably try to put something like this in it and experiment with it, but I'm not right now, so I'm not really sure exactly what conditions to do it under. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121
minshall@kinetics.UUCP (Greg Minshall) (05/20/88)
(I said I listen for RIP packets to find a gateway. Frank Kastenholz responded...) > This assumes that your host can understand that the packet is a RIP > packet. If my routers use another IGP then the hosts will not know that > it is an IGP packet so they can not "backtrack" to the source of the > packet and get a router. Yes, I understand that. That's why I would like one protocol which says "I am a router" that *everyone* uses. Today, however, there is no such protocol. As a practical matter I use RIP (and wouldn't mind using a few more). (I said...) > >I also feel for those souls whose routers occasionally crash, and who would > >like routes to switch automatically. I don't believe that just because > >you need this capability once per day that should exclude it from being > >automated. > Unfortunately I must strongly disagree with the last sentence. TCP/IP is > entering the non-technical world very rapidly. The company that I work >... > and more networks. the failure recovery mechanism MUST BE AUTOMATIC. The > recovery mechanism is required for a very simple reason - money. ... Sorry. I was in "poor English" mode. You and I are in total agreement. I worded my sentence poorly. Greg Minshall Kinetics, Inc. (415)947-0998 ...ucbvax!mtxinu!kinetics!minshall