kzm@ACC-SB-UNIX.ARPA.UUCP (04/05/87)
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.
Mills@UDEL.EDU.UUCP (04/05/87)
Keith, The mechanism I suggested some time ago involves cacheing ICMP messages of selected types for a period longer than the typical TCP retransmission interval, but shorter than the typical "retry" interval, maybe a couple of minutes or so. I did not specify which message types should be cached and what detail information (TOS, etc.) should be saved, but did assume as much information as useful in the routing algorithm. My suggestion would not affect routing until a number of these messages (tbd) had been received within a period equal to some number of TCP retransmissions, maybe fifteen to thirty seconds. When that happened the local routing data base would be marked "down" for that destination net/TOS/whatever and the normal routing exchanges would do the rest. You will note this is functionally identical to the hard-to-reach concept used in the telephone network, except that routing updates per se are not used in that network (#4 ESS non-hierarchical routing honkers will be politely ignored here). I am not suggesting now as the optimum time to construct a definitive proposal on how to implement this concept in a j-random gateway, but am suggesting the concept ripe for experimentation in a real gateway, maybe even a fuzzball. Dave