Subject: RE: What is Handover? (was: Re: [Seamoby] Examples of CAR discove ry)

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 13:51:58 -0500

James:

  My position on CAR/CT/whatever is that it would be nice to have as
many tools as possible to promote seamless handovers in any wireless 
scenarios. Seamless (in my view) means unnoticeable by the end-user, 
which is actual a very broad definition, allowing lots of negative
effects to be tolerated at lower layers (e.g. look at a typical 2G/3G
handover). However, as an IETF wg we struggle to deal with the gap
between "user perception of QoS", (for which there is no real definitive
body of work, except for voice), and L2/L3 performance. It doesn't help
that it is outside of the scope of a wg to discuss performance except in 
very relative, qualitative terms.

  In opposition to the struggle for seamless handover are the costs: 
measured in the wireless IP world in terms of complexity, saleability, 
overhead, over-the-air bandwidth use. Since no one knows how much revenue
will be generated by wireless data, it is not possible to set a limit on
the "tolerable cost".

  My points are that in any wireless handover situation, the net objective
is to hide the handover from the end-user. This is as true for
inter-technology 
handovers as it is for intra-network handovers. There is a difference in 
difficulty in achieving these goals, but the difficulty of the solution 
should not change the objective.

  To respond your three points: 

  1) handover is a necessary evil which is intrinsic to the network service.

IMHO, it is up to the network to maintain the service level, not the device.

I am not a proponent of "dumb devices", but there is an economy of scale in
putting certain support in the network rather then the device. As a counter
analogy, why do hosts not determine the forwarding route for an IP 
packet? 

     BUT, you will say, the MN knows best what services it needs. Poppycock,
the applications running on the MN know best, and if things get that bad,
there
are mechanisms being worked on to mitigate QoS changes at the application
(e.g.
MPEG-4 adaptive coding). These mechanisms cannot be relied upon, in general,

for a variety of reasons not worth getting into here, but the provide a last

measure for recovery.

  2) If handover is treated as a link/routing failure, then I would propose
that
NSIS is the better answer. The reasons being that a) the service has already
been
lost; b) there is no real way of determining how far the "link/route
failure" extends.
With respect to (a): yes, one could switch links so quickly that impact on
QoS is
marginal at the IP layer, but this would require "micromobility"-like link 
re-establishment/re-routing, which for the moment is a big assumption
(clearly
this statement is more valid for inter-technology handover then for, say,
soft
handover in CDMA). 

     With respect to b), I can only ask the question: is it reasonable to
assume
that a link/routing failure is always localized, and does not effect the
path? 
If the path is effected, then something more is involved then simple access
point
selection. Yes, the offering at each access point might be engineered such
that the corresponding paths are available for each QoS. However, I find it
difficult
to understand how this differences can be accurately capture with some
advertisement
to the MN, in what would have to be a standardized format. If the
standardized format
was, for example, DS code points, then I don't see what decision is to be
made by the MN. 
Is it not enough for the new network to say either it supports DSCP nnnn or
not?

  3) see above.

  It should be evident from the above that I see a lot of functionality
being proposed 
to re-establish QoS during handover. rather then sustaining it. For example
100ms drop 
in service is anywhere from 5 to 10 voice frames dropped. This is a
noticeable audio 
effect, even if it occurs rarely. For me, this approach brings into question
the whole 
concept of what QoS during handover really means. 

My vision for CT included inter-network, intra-network and inter-technology
handover. 
It is my expectation that CT will not be performed between unfriendly or
unacquainted 
operators, and that, at worse, there will be SLAs in place for service, QoS,
and AAA
considerations. 

  Whatever solutions are derived must work together, and independently, that
latter allowing network designers to experiment with the technology and find
the 
best solution for each network operator.

Just my delusional opinion,
Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: April 2, 2002 12:14
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Satish Jamadagni'; Nakhjiri
> Madjid-MNAKHJI1; 'Hemant Chaskar'; [email-masked]
> Subject: What is Handover? (was: Re: [Seamoby] Examples of CAR
> discovery)
> 
> 
> Gary/All,
> 
> So I think what it comes down to is this. Is handover:
> 
> 1) An opportunity for the mobile node to express its preferences for a
> new access router with characteristics that better match what 
> the mobile
> node and its user need,
> 
> 2) A link/routing failure that needs to be fixed up as quickly as
> possible.
> 
> 3) Both of the above.
> 
> Most of the discussion/disagreement/confusion (including my own) I've
> seen on this list seems to revolve around this question.
> 
> My opinion:
> 
> For intratechnology, Door Number 2.
> 
> For intertechnology, Door Number 1.
> 
> Comments?
> 
>             jak
> 
> ----- Original Message -----
> From: "Gary Kenward" <[email-masked]>
> To: "'Satish Jamadagni'" <[email-masked]>; "Nakhjiri
> Madjid-MNAKHJI1" <[email-masked]>; "'Hemant Chaskar'"
> <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 02, 2002 7:25 AM
> Subject: RE: [Seamoby] Examples of CAR discovery
> 
> 
> > Satish:
> >
> >   The reason that CT should remain separate from CAR is that
> > CT is useful in many scenarios where CAR is not required. Consider
> > the (trivial) case of an access network engineered to provide all
> > the necessary QoS capabilities at each AR (note: this does not mean
> > that the network is homogenous, just designed/configure with
> forethought).
> >
> >   Indeed, if saving time during handover is the issue, then it is
> > always faster to do as little signalling as possible, which, for
> > some networks, would be CT without CAR.
> >
> >   A similar argument can be put forth for the use of an 
> NSIS solution
> > during handover. Note that I am talking in the general case here,
> there will
> > always be situations where the network (including the MNs) will have
> to
> > resort to signalling to maintain or re-establish sessions. 
> Mobility is
> > always about probabilistic success, and it is overkill to 
> apply worse
> > case solutions to all scenarios.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Satish Jamadagni [mailto:[email-masked]]
> > > Sent: April 2, 2002 00:39
> > > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; [email-masked]
> > > Subject: Re: [Seamoby] Examples of CAR discovery
> > >
> > >
> > > Hi All,
> > > I feel that CT and CAR should go hand in hand. The reasons
> > > are as follows
> > > (taking a Bottom - Up approach trying to arrive at a CAR
> > > protocol from a
> > > final TAR selection perspective assuming that this is what
> > > CAR discovery is
> > > supposed to assist in)
> > >
> > > Combining CT and CAR -
> > > 1. Saves signaling time (Time is one of the main factors for
> deciding
> > > seamless ness)
> > > 2. Makes sense as during a seamless HO "Context" preservation
> > > is what every
> > > mobile terminal aims at (we are not considering application
> > > adaptation and
> > > such kind of stuff)
> > > 3. Typical TAR selection would be based on a "MATCH" of the
> > > MN context and
> > > the AR context support capabilities (any other policies and
> > > user fancies can
> > > also be brougnt under the "Context" perspective (I assume
> > > that "context"
> > > reflects a desired QoS feel at the MT so for all 
> practical purposes
> > > "Context" and QoS are the same).
> > >
> > > For a TAR selection the MT would send in his present
> > > "Context" list to find
> > > a match. This I guess would be sent to all CARs (with all the
> > > signaling
> > > overheads)
> > >
> > > So for all practical purposes by the time I would have done a
> > > TAR selection
> > > I would have at least achieved a partial CT if the new AR can
> > > preserve the
> > > messages that I use for initial inquiry for TAR selection.
> > > All other CARs
> > > where the MT would have sent a message with a wish list ( its
> present
> > > context) can release the context list if the MT finally does
> > > not choose them
> > > based on a timer.
> > >
> > > So I feel a CAR discovery protocol SHOULD identify and standardize
> "an
> > > ABSTRACT Context" notion for initial CAR selection and finally
> should
> > > provide for classes of Contexts to ease the TAR selection
> > > process. The exact
> > > match algorithms  can be left to implementations. Such
> > > classes of contexts
> > > helps in either a partial or a full CT under TAR selection itself.
> > >
> > > Combining CT and CAR has signaling advantages and this can
> > > prove critical
> > > for a seamless handover where the "objective is Zero latency
> handover"
> > >
> > > Regards,
> > > Satish Jamadagni.
> > >
> > >
> > > ----- Original Message -----
> > > From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
> > > To: "'Hemant Chaskar'" <[email-masked]>; <[email-masked]>
> > > Sent: Tuesday, April 02, 2002 5:46 AM
> > > Subject: RE: [Seamoby] Examples of CAR discovery
> > >
> > >
> > > > Bingo, Hemant,
> > > >
> > > > you hit it right in the bulls eye. CAR discovery is
> > > > about finding the destination, CT will happen after you found
> > > > the destination. QoS CT will only help maintaining QoS after
> > > > (or during) the handoff, but it cannot be used to determine
> > > > where to handoff to.
> > > >
> > > > Madjid
> > > >
> > > > -----Original Message-----
> > > > From: Hemant Chaskar [mailto:[email-masked]]
> > > > Sent: Monday, April 01, 2002 10:45 AM
> > > > To: [email-masked]
> > > > Subject: Re: [Seamoby] Examples of CAR discovery
> > > >
> > > >
> > > > Hi James:
> > > >
> > > > Pardon my ignorance here, but isn't CT about *transferring*
> > > context rather
> > > > than negotiating capabilities. In other words, doesn't CT
> > > protocol take
> > > > source and dest. of CT as input? Now, source is obvious, we
> > > still need to
> > > > work on finding dest. which is target AR of handoff.
> > > >
> > > > BR,
> > > > Hemant
> > > >
> > > >
> > > > >From: "James Kempf" <[email-masked]>
> > > > >To: "Charlie Perkins" <[email-masked]>
> > > > >CC: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
> > > > >Subject: Re: [Seamoby] Examples of CAR discovery
> > > > >Date: Mon, 1 Apr 2002 08:16:02 -0800
> > > > >
> > > > >Hi Charlie,
> > > > >
> > > > >
> > > > > > Lastly, we have already some evidence that handing QoS from
> one
> > > > > > access router to another access router is about the
> > > same as handing
> > > > > > any other context between routers -- again, under the
> > > assumption that
> > > > > > the basic authorization has already been negotiated at
> > > some time in
> > > > > > the past.  There is no need to have two protocols where
> > > one is better,
> > > > > > regardless of political divisions within the IETF.
> > > > > >
> > > > >
> > > > >This sounds like context transfer, not CAR discovery. QoS
> > > was one of the
> > > > >intended applications of context transfer, so I believe it
> > > is in scope.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > > >_______________________________________________
> > > > >Seamoby mailing list
> > > > >[email-masked]
> > > > >https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > > >
> > > > 
> _________________________________________________________________
> > > > Chat with friends online, try MSN Messenger:
> > http://messenger.msn.com
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
>

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 13:51:58 -0500

James:

measure for recovery.

  3) see above.