Subject: Wording for "Recovery from Subnetwork Outages"

From: Phil Karn <[email-masked]>
Date: Thu, 9 Mar 2000 17:39:23 -0800

Here's the text I just wrote for the PILC LINK document that discusses
subnetwork mechanisms that could speed up TCP's recovery from a
temporary subnetwork outage. I put it in a new section titled
"Recovery from Subnetwork Outages". This is the "implicit" alternative
to the ICMP Source Encourage message that I discussed earlier.

--Phil

Some types of subnetworks, particularly mobile radio, are subject to
frequent temporary outages. For example, an active cellular data user
may drive or walk into an area (such as a tunnel) that is out of range
of any base station. No packets will be successfully delivered until
the user returns to an area with coverage.

The Internet protocols currently provide no way for a subnetwork to
explicitly notify an upper layer protocol (e.g., TCP) that it is
experiencing an outage, as distinguished from severe congestion.
Under these circumstances TCP will, after each unsuccessful
retransmission, wait even longer before trying again; this is its
"exponential backoff" algorithm. And since there is also currently no
way for a subnetwork to explicitly notify TCP when it is again
operational, TCP will not discover this until its next retransmission
attempt. If TCP has backed off, this may take some time.  This can
lead to extremely poor TCP performance over such subnetworks.

It is therefore highly desirable that a subnetwork subject to outages
not silently discard packets during an outage. Ideally, it should
define an interface to the next higher layer (i.e., IP) that allows it
to refuse packets during an outage, and to automatically ask IP for
new packets when it is again able to deliver them. If it cannot do
this, then the subnetwork should hold onto at least some of the
packets it accepts during an outage and attempt to deliver them when
the subnetwork comes back up.

Note that it is *not* necessary to avoid any and all packet drops
during an outage. The purpose of holding onto a packet during an
outage, either in the subnetwork or at the IP layer, is so that its
eventual delivery can implicitly notify TCP that the subnetwork is
again operational.  This is to enhance performance, not to ensure
reliability -- a task that as discussed earlier can only be done
properly on an end-to-end basis.

Only a single packet per TCP connection need be held in this way;
subsequent packets can either replace the existing packet, or they can
be discarded. Either way, TCP will quickly recover from these
additional losses once the flow resumes.

Because it would be a layering violation for IP or a subnetwork to
look at the TCP headers of the packets it carries (which would in any
event be impossible if IPSEC encryption is in use), it would be
reasonable for the IP or subnetwork layers to choose, as a design
parameter, some small number of packets that it will retain during an
outage.