Subject: [mobile-ip] Low Latency Issue: Where to Run the Reverse Tunnel?

From: James Kempf <[email-masked]>
Date: Thu, 30 Aug 2001 10:50:51 -0700 (PDT)

The MIPv4 low latency handoff draft specifies that when egress filtering
is on, the new FA needs to run a reverse tunnel in order to prevent
outgoing packets from the MN from getting dropped. This is required
for POST-REGISTRATION because it is fundamental to the protocol and
for PRE-REGISTRATION in case L3 handover does not complete prior
to L2 handover. Egress filtering causes packets to drop on the new
subnet in cases where there is no route optimization and
the home address is being used as the source address, and if route
optimization is in effect and the old CoA is being used, perhaps
temporarily, as the source address.

Note that if the new subnet is not doing egress filtering, no 
reverse tunnel is required.

The two possible places to which the tunnel could be run are:

1) The HA, as would be required at any FA where egress filtering
is on and the there is no route optimization.

2) The old FA, as is done in BETH for FMIPv6.

The authors are in general agreement that the tunnel should be run
to the HA. 

In favor of the old FA: If route optimization is in effect, the tunnel
must be run to the old FA because the source address on the MN's packets
will be on the old FA's subnet. If they are tunneled to the HA's subnet,
the ingress filter on the HA's subnet may drop them. In addition,
tunneling them to the HA will require a preregistration transaction
between the HA and the new FA, otherwise the HA is in danger of
dropping the packets because the new FA is not yet known. This
transaction will add to the latency of handover, in particular, because
the topological distance between the new FA and the HA is likely to
be longer than the distance between the old and new FAs.

In favor of the HA: Route optimization is not currently deployed, nor
does it look likely to be deployed any time in the near future. Should
route optimization be deployed, we can modify the protocol to allow
tunneling back to the old FA. The new FA will need to tunnel to the HA anyway 
when the MN performs L3 handover and obtains its new CoA. Since the old FA will 
be tunneling to the HA, tunneling to the old FA then to the HA is
less efficient than simply tunneling directly to the HA. In addition, tunneling 
to the HA is required for GRE due to the need for authentication, so tunneling 
to the  HA simplifes the protocol if it is used in all cases. The additional
amount of latency added by the preregistration should not be extreme,
and the FA can buffer outgoing packets until the registration reply
is received, or opportunistically send them to the HA in anticipation of
a successful preregistration.

The authors would like comment, particularly whether the working group
agrees with the authors' opinion that tunneling directly to the HA
is the right solution.

		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 30 Aug 2001 14:05:54 -0700 (PDT)

Here's my opinion about one particular aspect of this issue:

>...
>
>In favor of the old FA: ...
> In addition,
>In favor of the HA: ...
> The additional

The RTT on the preregistration request/reply could cause
a significant increase in latency on the handover (like, say, 60 ms if
I am in California and my HA is in New Jersey, or 160 ms if I am
in Minneapolis and my HA is in Germany), to say nothing of the packet 
getting dropped because it is sent UDP. The indicated
mitigating measures are relatively unattractive. Optimistically sending
the packets runs the risk of the HA dropping them if the preregistration
packet never got there, buffering them runs the risk of propagating
the latency and causing user perceptible artifacts in the real time stream.
One solution would be to deploy regional registration. This would
reduce the latency somewhat, but not eliminate it completely. In addition,
regional registration is currently not widely deployed and its prospects
are uncertain, whereas the need for low latency handoff is very acute
and the prospects for immediate deployment are fairly good.

		jak