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

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

> IMO unless we finish the work off people won't have a chance
 > to see if it fits their requirements. Until we have an RFC we
 > can't really say IETF has a stable solution for low latency
 > MIPv4 handoffs which people can implement and try out. Early
 > implementation is useful but few implementations doesn't
 > mean it shouldn't make it to RFC. We also need to consider that
 > low latency is closely knit to wireless (through L2 triggers and
 > their timing) which makes the real implementation harder than
 > many other drafts.
 > 
 > GT> I think that the community has been overwhelmed by the 
 > MIPv6 security
 > discussion and has reviewed the fast handoff specs very 
 > little. Also these
 > specs are full of new mechanisms...some of them very 
 > complex. Fast handoffs
 > are also "optimizations" and as Eric N. said recently, IETF 
 > is not very good
 > at producing optimization techniques. Even worst, parts of 
 > the fast handoff
 > specs are about optimizing the optimization...see Handoff To Third
 > (HTT)....what about the Forth, Fifth and Hundredth? What I 
 > am saying is that
 > the IETF must be very careful and rather conservative in this
 > standardization effort. Peer review and experimentation is 
 > needed here more
 > than anywhere.

I agree that experimentation is useful. The point is that here
experimentation is not easy since you need to make this work with
your wireless L2, so we can't expect everyone to implement it
or for it to fit all wireless systems. If there's no stable solution
there's no chance wireless people will implement this, so it would be
like going round in circles if we didn't finish this work. The lack of
fast MIP handoff on most L2s (as you say those which do not allow the
make-before-break where the MN talks both to oFA and nFA contemporarily)
has been given as a problem of Mobile IP which we aim to solve in low
latency. That's stated in the spec and is as far as this draft goes.
Regarding the optimisations I agree things should be kept simple but so
far people have not opposed things like HTT. By the way, HTT is a SHOULD
for those wireless systems where the MN moves fast enough for it not to be
able to register with nFA. It isn't needed for all cases. If you want
to propose ways of simplifying the spec like removing HTT or other parts
while keeping the basic functionality and the WG agrees I'm all for it.
My point is that this doesn't justify putting low latency on hold.

 > In fact the PFANE is sent by the MN along with the registration
 > request when it has attached to the new FA and is completing the
 > L3 handoff. The low latency solutions aim at reducing L3 handoff
 > latency to zero, which means that the MN must be in communication
 > as soon as it attaches to the new FA.
 > 
 > GT> The point is though that PFANE extension has been very 
 > stable for long
 > time and provides lossless handoff that can be used in the 
 > short term and
 > until either fast handoffs mature or link layers get make 
 > before break
 > capability...in which case fast handoff specs are not 
 > needed. The only
 > reason PFANEs are not a standard today is because they are 
 > part of the Route
 > Optimization draft that is notionaly kept behind because of the MIPv6
 > security discussion. Yet PFANEs have no security issue 
 > themselves...hence
 > the discussion about publishing them independently of 
 > Routing Optimization.
 
I'm not against splitting PFANE from route opt. since I agree that
it solves a different problem than generic route opt.
However I can't agree with the argument that PFANE can be used for
loss-less handoff on the way to a next step. PFANE in route opt
is used after the MN has attached so that implies some latency/loss.
I say we provide the necessary fast handoff tools and let people
make their implementation choices.

/Karim

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Dec 2001 10:56:12 -0800

> or for it to fit all wireless systems.

I disagree. Simulation has proven successful in a variety of
areas (particularly with routing protocols), and I think it
can be used quite successfully here. If one implements
the protocol for one particular wireless L2, that only proves
it works for that particular wireless L2. For another
wireless L2 with different properties, it may not
work.

>If there's no stable solution

Making it experimental should solve this problem.

> My point is that this doesn't justify putting low latency on hold.

Making it experimental isn't putting it on hold, it is saying that we
don't know enough yet to make it standards track.

> is used after the MN has attached so that implies some latency/loss.

I disagree. If the old FA buffers traffic until it receives the PFANE
message, lossless handover is possible. The techniques
in the low latency draft require exactly the same support.
Buffering is required in any case during L2 handover when there is
absolutely no way to get traffic across L2 to the MN.

> make their implementation choices.

If the IETF is approving a protocol with a performance claim,
then I think it is incumbent upon the authors of the protocol
that they prove that claim. A protocol that claims to be
have lower latency than standard MIPv4 should define when
it does and when or if it doesn't. The IETF isn't an
academic conference, it's a standards body. RFCs
are designed to be implemented and deployed. If the
IETF is making a recommendation that something
be implemented and deployed, it had better have
confidence that the protocol does what it says.

What ever happened to "running code?"

            jak