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

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 19 Dec 2001 16:17:00 +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.

 > 
 > Second, it was proposed that PFANE from the RO draft might 
 > be stripped
 > into a separate draft to accelerate progress on low latency. 

The previous FA extension has no relation to the low latency draft.
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.

/Karim

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Dec 2001 10:12:42 -0800

Just a minor comment.

Anything that uses L2 triggers is extremely hard to implement
in a small laboratory kind of place. That is why you dont
see any implementations.

the same thing goes for FMIPv6. it is easy to implement the
anticipated part of it. Tunnel based handovers are just not
possible for us.

Vijay

---

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

Karim,

> to see if it fits their requirements.

Well, this seems sort of backwards to me. Requirements should
be done first. However, in this case, we went right to
the solution because at the time we started the work,
there was a perceived need to have
the solution done quickly. If that need has abated or people
have changed their minds, then we need to revisit.

> Until we have an RFC we

I think it is as important to have running code as to have rough
concensus. The difficulty with this work is that it is making
a performance claim. IETF has difficulty with performance claims,
since typically all that is important to approve a protocol
for draft standard is that the code run and some degree of
interoperability be
demonstrated. For proposed standard, even that level of implementability
is not necessary, except for routing protocols. Arguably, MIP is
a routing protocol, but recently the IESG seems to be backing
away from treating it like one.

My own opinion is that the IESG ought to require a protocol
making a performance claim to demonstrate that claim,
and, in particular, demonstrate when the claim holds
and when it doesn't. If there are other, similar protocols
that can make an equivalent or better claim that is
more broadly applicable, obviously they are better
candidates for standardization. Charaterizing a protocol
with a performance claim is critical for implementation
and deployment.

> as soon as it attaches to the new FA.

PFANE is a form of "forwarding from previous care of address", which
provides an alternative to Prereg. Like Prereg, it allows the
MN to control movement. Because it is sent after the MN
moves to the new FA, it does not suffer from the problem of
having signaling cut off before completion, requiring the MN to
recover on the new FA, as does Prereg. Because it allows
the old FA to tunnel traffic for the MN, it maintains connectivity
until the routing update is done through the HA.
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. 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.

Thus, I think PFANE is quite relevent to the low latency
work. I believe that it should be moved from the route
optimization draft to a separate draft, because the security
issues are much more straightforward. PFANE involves
security between FAs, which is solved problem, and not between
the MN and an arbitrary CN, which has proved a fairly
difficult problem to solve. Keeping these security issues
separate will help facilitate IESG approval.

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.

            jak

---

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

Vijay,

Simulations are always possible. That's what we did. 

People have been using simulations to validate
the scalability of routing protocols for years. It is not possible
to deploy a huge network to test a routing protocol,
but a simulation can do it. 

I think this case is similar. It is not possible to implement
and deploy on all possible wireless protocols, so
a simulation that captures the important characteristics
of wireless protocols can help to characterize the
protocol.

I really hope others will do some simulation work,
and also for the FMIPv6 protocols.

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Dec 2001 00:08:27 +0100 (CET)

> demonstrated.

Agreed that the IETF doesn't deal well with cases when there are
multiple proposals that optimize the same type of thing which results
in different performance benefits perhaps in different situations.
The only tool we have for this is "does the community consider it useful" and
the only way we have to measure this in the interest to implement a particular
proposal.

> For proposed standard, even that level of implementability

The IESG always welcomes interoperable implementations before making
something a proposed standard. I don't think we've had a formal
discussion regarding RFC 1264 for any routing protocol while I've been
on the IESG.

> with a performance claim is critical for implementation

I think the IESG has enough to do already.
So while I encourage folks to think quantitively about performance
optimizations (analysis on paper, simulation, or actual tests) I don't think
this will resolve the issue.
Some folks might think implementing a 300 page RFC for a 3% performance
gain is worth while, whereas others would like to see a 300% performance
gain before they implement a 3 page RFC.
This is fundamentally an engineering tradeoff that needs to take into
account not only the complexity/performance tradeoff but also things
like the environment, what type of applications will use this (and what
assumptions will they make about packet drop behavior, delay etc),
and the observation that the probability of interoperability
is inversely related to the complexity of the spec.

And the only "tool" we have for to determine this is whether two or more
implementors find the protocol useful enough to do a complete implementation.

> [...]

I think upleveling in general is a resonable approach for optimizations
in general so try to guage during the process of developping an idea
whether folks think it is useful enough.
But this requires work by the WG participants to make the determination
whether they individually think it is worth while to implement a protocol
and having performance data would presumably be helpful for the WG
participants.

  Erik