Subject: RE: [mobile-ip] WG Feedback Requested

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 19 Dec 2001 19:45:26 +0100

PFANE is an extension of the registration request so it's not really an
alternative. PFANE can be used as an extension to the pre-reg registration
request but I'm not necessarily saying this is a good idea.

 > Based on our experiments with a similar, though slightly different,
 > technique, PFANE is likely to perform about as well as Prereg
 > when the MN is moving at the optimal speed, and much better where
 > Prereg performance deteriorates as the MN moves faster
 > or slower than the optimal speed.

What is this optimal speed? Optimal for who? Hopefully not
Schumacher in his Ferrari ;-)

 > It should also perform
 > better than standard MIPv4 handover because the MN
 > doesn't have to wait for routing to change at the HA, but
 > not as good as Postreg because of the delay associated with
 > L2 handover and PFANE signalling. Of course, to verify
 > this, we will have to test PFANE.

How can pre-reg which anticipates the mobility be worse than
a protocol which runs after then MN has moved?

 > However, I really think we need to uplevel the context
 > here a bit and look at the meta-issue. Phil's question at the meeting
 > about who was going to implement this work was not encouraging.
 > I had thought that 3GPP2 was an obvious customer,
 > but they already do something like Postreg for PPP.
 > If nobody is going to implement this work, or it
 > will just be implemented as a research project, then what
 > is the point of doing it? We should just make the whole
 > thing experimental and concentrate on getting FMIPv6
 > right.

I think I've already said what I think about the implementation issue.
If we don't have a spec which is stable enough we're just going in circles.
How do you know what FMIPv6 is going to be used for? If you apply this
argument to low latency soon people will be applying the same to
FMIPv6 and we'll just go back to where we started. We should just
get low latency into some RFC form, do the same for FMIPv6 once
MIPv6 is done and put this issue aside awaiting real deployment.

There have been several specs which were not used because they
were not RFCs. 3GPP2 could well be a good example and provide a
reason why this work needs to be completed. RFCs can get revisited
as it becomes clear changes are needed.

/Karim

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Dec 2001 11:33:43 -0800

Karim,

> request but I'm not necessarily saying this is a good idea.

It is an alternative because it does forwarding from previous FA by
tunneling, exactly like Postreg, so the MN keeps getting its
traffic while routing is updated on the HA.

> Schumacher in his Ferrari ;-)

Given a 10 ms latency on the radio link, movement of
the MN is such that:

For a 9.6 kbps radio link, the time between L2 handover
and the prehandover  trigger is between 110 and 300 ms.

For a 15 kbps radio link, the time between L2 handover
and the prehandover trigger is between 65 and 160 ms.

For a 300 kbps radio link, the time between L2 handover
and the prehandover trigger is between 20 and 80 ms.

That's what I mean by optimal. For other radio link
latency and other data rates, the region is different
(which is part of the problem).

> a protocol which runs after then MN has moved?

Because if the MN is moving so fast that it fails to complete
the Prereg signaling on the old FA, it needs to recover
with standard MIPv4 signaling on the new FA. While
on the old FA, data traffic is blocked because of
the Prereg signaling. While on the new FA, it can't
get traffic until the routing changes on the HA.
Please see
http://geocities.com/kempf42/llanalysis.pdf
for details.

> as it becomes clear changes are needed.

I agree that the specs need to be stabilized. The question before the WG
is how. I don't want something to get the imprinteur of an IETF standard
before it is well understood and known to work.

            jak