Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!TOPAZ.RUTGERS.EDU!hedrick
From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  TCP requesting ARP flushes and other "layering violations"
Message-ID: <8710271929.AA24562@topaz.rutgers.edu>
Date: Tue, 27-Oct-87 14:29:09 EST
Article-I.D.: topaz.8710271929.AA24562
Posted: Tue Oct 27 14:29:09 1987
Date-Received: Fri, 30-Oct-87 02:49:42 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 21

Actually, 4.3 already has a procedure whereby TCP can notify the lower
levels that a connection is failing.  It's not obvious to me that this
is a layering violation.  It seems to me that the TCP layer is the
only one that can know when things are timing out, and that having it
notify the layer that knows wha to do is perfectly appropriate.  What
would be wrong would be for the TCP code to directly manipulate the
routing database.  Currently this notification has an effect only for
routes that are going through gateways.  It marks the route as down.
In my view it would be perfectly appropriate that if a route is local,
the arp entry should be killed.  Indeed I have considered adding such
code, and may yet do so.  Our main problem with this mechanism is that
not all applications use protocols that can detect failure in this
way.  E.g. the domain system does not.  Of course named does retry,
but the retries are done at the application level.  Unless we have
every program that does this use an ioctl to notify the system that a
route is failing, we can't depend upon this mechanism.  This wouldn't
really be a layering violation, but it would be ugly.  I'm still not
sure what the right solution is, but we now have enough redundancy in
our network that it is worth coming up with one, and I am committed to
doing so soon.  I can't simply run routed on each machine, because
that will cause synchronized paging on diskless machines.