Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!ACC-SB-UNIX.ARPA!kzm
From: kzm@ACC-SB-UNIX.ARPA.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Wiretapping ICMP messages
Message-ID: <8704042139.AA28927@ACC-SB-UNIX.ARPA>
Date: Sat, 4-Apr-87 16:39:43 EST
Article-I.D.: ACC-SB-U.8704042139.AA28927
Posted: Sat Apr  4 16:39:43 1987
Date-Received: Sun, 5-Apr-87 13:13:24 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 32
Approved: tcp-ip@sri-nic.arpa


There have been a number of suggestions on this list recently that
congestion-control could be enhanced if various IP implementations 
took note of ICMP Destination Unreachable messages, eg. if gateways
cached the information and refused to send packets based on this 
cached information.  It appears to me that this could cause problems 
when the routing and congestion algorithms are upgraded to include 
TOS-routing, Precedence, and Security.

TOS-routing may not be available yet, but it appears to be considered
a desirable addition in the (not too distant) future.  When it is 
available, a destination might be reachable with one TOS value, but
not with another.  Similarly, there is work underway to have packets
queued in switches (eg. in IMPs) according to their Precedence.
So, a similar scenario (reachable with a high Precedence value,
but not with a low value) could be applicable here also.  The use
of Security information as a routing criteria may be further into
the future, but the same considerations apply.

Of course, the cached information could be expanded to include TOS,
Precedence and Security along with the destination address.  The size 
of the cache would increase, but probably manageably-so for the time
being while the majority of packets have the same TOS/Precedence
/Security values.  However, this could cause a "scaling-up" problem 
in the future.  Also, the mechanism loses some of its usefulness when
it can only be applied to packets of the same TOS, Precedence, and
Security.  Again, this might not a problem today when the majority of 
packets have the same TOS/Precedence/Security values, but does it 
cater to the future ?

Keith McCloghrie
ACC, Columbia Md.