Re: Network layer reqt? [was Re: Transport level multihoming]

[Thomas Narten <narten@raleigh.ibm.com>]

> In my experience it is usually only severe turbulance which triggers
> an ICMP back to an endpoint that causes sessions to die; multi-minute
> packet loss due to loops in response to re-homing is not altogether
> usual, I think.

note: typical ICMP errors generated as a result of route flaps/hiccups
that are sent back to an originating end system do not/should not
cause sessions to die. RFC 1122 makes this clear. I've appended an
excerpt from 1122 on this topic.  Note also, that pretty much all TCPs
seem to do the right thing now, though it took many many years.

Thomas

         4.2.3.9  ICMP Messages

            TCP MUST act on an ICMP error message passed up from the IP
            layer, directing it to the connection that created the
            error.  The necessary demultiplexing information can be
            found in the IP header contained within the ICMP message.

            o    Source Quench

                 TCP MUST react to a Source Quench by slowing
                 transmission on the connection.  The RECOMMENDED
                 procedure is for a Source Quench to trigger a "slow
                 start," as if a retransmission timeout had occurred.

            o    Destination Unreachable -- codes 0, 1, 5

                 Since these Unreachable messages indicate soft error



Internet Engineering Task Force                               [Page 103]




RFC1122                  TRANSPORT LAYER -- TCP             October 1989


                 conditions, TCP MUST NOT abort the connection, and it
                 SHOULD make the information available to the
                 application.

                 DISCUSSION:
                      TCP could report the soft error condition directly
                      to the application layer with an upcall to the
                      ERROR_REPORT routine, or it could merely note the
                      message and report it to the application only when
                      and if the TCP connection times out.

            o    Destination Unreachable -- codes 2-4

                 These are hard error conditions, so TCP SHOULD abort
                 the connection.

            o    Time Exceeded -- codes 0, 1

                 This should be handled the same way as Destination
                 Unreachable codes 0, 1, 5 (see above).

            o    Parameter Problem

                 This should be handled the same way as Destination
                 Unreachable codes 0, 1, 5 (see above).