Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

From: Phil Roberts <[email-masked]>
Date: Wed, 25 Jul 2001 14:03:44 -0400

> Well, I understand where you are coming from, as I would like 
> a complete
> handover solution to be done soon too. But realistically, it takes as
> long as it takes. If we can peel off the FMIP work and get IESG to
> take a look at that, we can reduce the amount of time later when
> we do reach concensus on smoothing.
> 
> I'd like to hear from the WG chairs and ADs on this, I guess, since
> it seems to me basically a procedural issue. Raj has already come
> out for keeping smoothing separate for now, what do the rest of
> you think?
> 
> 		jak
> 

I wouldn't call it a procedural issue but a need to make a decision.  I
(personally)
would like to make a consensus call on both FMIPv4 and FMIPv6 right after
London and I don't want to send up drafts one with and one without an option
for smoothing.  So our consensus calls will probably be something like 1) do
we want smoothing in a separate draft and if so, 2) is FMIPv6 ready for last
call and is FMIPv4 ready for last call after we remove the smoothing bits;
and
if not 3) is FMIPv4 read for last call and FMIPv6 ready for last call after
we add the smoothing bits.
  
Right now it seems that George at least is uncomfortable with making
smoothing an essential part
of the FMIP draft.  Hesham at least is uncomfortable with progressing the
FMIP draft without smoothing.  Hesham's position excludes the middle ground
of putting smoothing into a separate draft.  As an aside it seems clear that
smoothing is an optional feature in the FMIPv4 draft but I'm not sure
whether
the proposal is to make it optional when incorporated in FMIPv6.

There does seem to be some consensus that if a smoothing technique is chosen
it should be through bicasting or simultaneous binding rather than some kind
of
buffering.  At the minimum we should have a discussion of why the tradeoff
of
accepting the possibility of duplicate packets weighs more heavily than
accepting
the possibility of lost packets and the results should be documented.

George has also asserted (and speaking for myself personally I also agree
with)
that implementations in some environments at least can solve this without
any kind
of protocol support at layer 3.

Does this seem to summarize everyone's position accurately?  Does this
answer your question
enough, Jim?

Of course, others contributing to the conversation COULD help,
Phil

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 25 Jul 2001 12:21:14 -0700

I unfortunately agree with most folks that disagree with each other. On
one hand, the low latency draft without smoothing techniques is incomplete,
but on the other hand, additional (and perhaps even better) techniques may
be developed over time.

So, one alternative is to add text to the fast drafts that without such a
technique, the draft is incomplete. Then the WG could develop a series of
smoothing techniques (perhaps each in separate drafts, but well identified). 

So, the fast draft does point to external work, and it does claim that by
itself it really is incomplete, but on the other hand, it isn't tied to
a specific mechanism, and allows for future extensibility.

My 2 cents,

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 25 Jul 2001 16:17:55 -0700

Hello Phil,

Phil Roberts wrote:
[snip]

> the possibility of lost packets and the results should be documented.

I would like to mention the issue surrounding header compression and bicasting.
I posted a separate e-mail on this topic BTW. The problem is what type of a
packet does the old-AR bicast ? If it is uncompressed, then the new-AR needs
compression context to forward the compressed packet to the MN. Unfortunately,
this means support for Many-to-One mode of header compression (the two ARs to
the MN) which to my knowledge has not been defined. Thanks [rohc]! If the
old-AR bicasts a compressed packet to the new-AR, how does the new-AR forward
that packet ?
In the uplink, only the old-AR would have the up-to-date context. This
introduces synchronization issues even when the new-AR may concurrently possess
the header compression state.

So, it is perhaps premature to state that there is consensus. I think bicasting
must not be coupled to FMIPv6. It could ofcourse be a separate draft.

My two cents..

-Rajeev