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

From: Rajeev Koodli <[email-masked]>
Date: Thu, 26 Jul 2001 10:27:39 -0700

Gary Kenward wrote:

>
>
> Rajeev:
>
>   Reading this email from you, I now understand better what you
> meant by "many-to-one" mode. My first response was talking about
> doing "many-to-one" above or after ROHC. I believe you are referring
> to performing the combining of the two streams within ROHC - a
> very powerful idea, given that the information from the two separate
> streams could be used to improve robustness. However, the complexities
>
> of this approach do scare me, and I would think that the algorithm
> would need much more research.
>
>   In the meantime, combining (or selecting) above ROHC would work,
> at the expense of running two independent ROHC decompressors at the MN
>
> (and probably two ROHC compressors for the traffic from MN to old and
> new AR respectively).
>

I also alluded to the last paragraph in my previous e-mail. The MN needs
two separate contexts for bicasting to work in downlink. In the uplink
however, the MN is not doing bicasting (ok, except in soft handover,
which may or may not be visible to IP). So, your last comment is not
valid. That is, only the context at the old-AR is current.

Reiterating my point, this must not be part of FMIPv6. Time permitting,
I will work on a separate draft for smoothing and HC and outline these
issues in detail.

-Rajeev

>
>   Comments?
>
> Gary
>
> > -----Original Message-----
> > From: Rajeev Koodli [mailto:[email-masked]]
> > Sent: July 25, 2001 19:18
> > To: [email-masked]
> > Subject: Re: [mobile-ip] Handover Smoothing - What to Do?
> >
> >
> > Hello Phil,
> >
> >
> > Phil Roberts wrote:
> > [snip]
> >
> > >
> > > 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.
> > >
> >
> > 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
> >
> >
> > >
> > > 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: "Gary Kenward" <[email-masked]>
Date: Thu, 26 Jul 2001 10:54:49 -0400

Rajeev:

  Comments?

Gary

> > Right now it seems that George at least is uncomfortable with making
> In the uplink, only the old-AR would have the up-to-date context. This
> must not be coupled to FMIPv6. It could ofcourse be a separate draft.
> 
> My two cents..
> 
> -Rajeev
> 
> 
> >