Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!mailrus!tut.cis.ohio-state.edu!bloom-beacon!husc6!spdcc!kaos!romkey
From: romkey@kaos.UUCP (John Romkey)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: hosts and gateways and protocols
Message-ID: <886@kaos.UUCP>
Date: 18 May 88 17:38:54 GMT
References: <8805161802.AA15658@mtxinu.UUCP>
Reply-To: romkey@kaos.UUCP (John Romkey)
Organization: Chaos; Somerville, MA
Lines: 25

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