Subject: RE: [seamoby] Re: draft-brain-seamoby-terms-00.txt

From: "Gary Kenward" <[email-masked]>
Date: Fri, 2 Feb 2001 10:41:03 -0500

Jukka:

  Comments inserted....

Gary

> -----Original Message-----
> From: Jukka Manner [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 7:00 AM
> To: [email-masked]
> Cc: Seamoby Working Group
> Subject: [seamoby] Re: draft-brain-seamoby-terms-00.txt
> 
> 
> 
> 	Gary,
> 
> 	Here are some (late) answers to your comments. I copy 
> this to the main
> Cmoby list to raise more discussion on the terminology of the draft.
> 
> 	Regards,
> 
> 	Jukka
> 
> On Thu, 18 Jan 2001, Gary Kenward wrote:
> 
> > Overall, I liked this draft, and the clarity and logic of 
> the definitions.
> > It goes beyond what we need for the CT problem statement, and so we
> > must be cautious not to rat-hole on issues such as paging. 
> Hopefully,
> > appropriate selections will be made in the problem statement draft
> > that Henrik is leading.
> 
> 	The draft was intended for the whole Seamoby WG, so 
> part of it is
> truly not needed in CT discussions. Hopefully the whole WG 
> will benefit
> from it.
> 
> >
> > Some specific comments/concerns:
> >
> > p5: section 2.2.2, Layer 2 handovers are not necessarily 
> intra-technology. I
> > have
> > misplaced the announcement, but at least one company is 
> working on dual mode
> > devices that will switch between Bluetooth and 802.11 
> without involving the
> > IP layer.
> 
> 	True. Perhaps we should then just change "necessarily" 
> to "typically".
> 
> >
> > p5: section 2.2.2, I did not understand the discussion on 
> Horizontal and
> > Vertical handover, and in particular how these definitions 
> mapped onto the
> > architecture. I'm probably missing some key IETF 
> nomenclature here, but if you
> > would help
> > me out, and explain the relationship between Horizontal and Vertical
> > handover
> > and inter- and intra- AR handover. If there is no 
> relationship, then one of
> > the
> > definitions would seem to be redundant.
> >
> 
> 	We try to see the handover event from the IP POV. When 
> the interface on
> the IP layer does not change, we can think that a pure layer 
> 2 handover
> happened, which remained (partially) unnoticed at the IP 
> layer. This was called
> horizontal. When the network interface clearly changes at the 
> IP layer, we
> called this vertical handover. The definitions come from 
> discussions on what to
> call handovers between different link layers. In future 
> wireless communications,
> a MH can do handovers from UMTS to GPRS to blue tooth to WLAN to
> any-network-you-like. Previously those were called vertical 
> and horizontal
> (change of link layer vs. no change in link layer). We tried 
> to adopt those and
> look at them from the IP POV.

These are the definitions that I am familiar with. They need to
be expanded upon in your document, for clarity. I'm still not sure
how this impacts the Seamoby solution, but then, we don't have a solution
yet and it is worth capturing.

> 
> 	The handover terms defined in 2.2.1 and 2.2.2 are 
> related to the context
> of discussions. They define somewhat similar handovers, but 
> for clarity and to
> provide less room for misunderstanding, we have defined that many.
> 
> In the definition of "Horizontal" we must replace "OAR and 
> NAR" with "AN".
> 
> 
> > p6: I do not agree that a planned handover is generally a 
> result of backward
> > handover. The definition of planned handover does not suffer if this
> > sentence
> > is removed.
> 
> Should we say that "planned assumes backward" - would that be 
> enough? I'm not
> sure whether a NAR can be chosen and be active to initiate 
> the handover.
> Wouldn't choosing a NAR be part of the handover procedure?

My point was that it is not necessary to tie the two definitions together.
Doing so presumes a certain solution set. 

> 
> 
> > p6: "planned" vs. "unplanned" don't work for me. they have 
> a connotation of
> > long term, slow. I'm not sure why you chose not to use 
> "proactive" and
> > "reactive",
> > and introduced "planned" and "unplanned" - the latter terms 
> don't really add
> > to the meaning. (one could be trite and say that a 
> "reactive" handover could
> > be planned).
> 
> To us this was a matter of taste. In the "literature", they are used
> synonymously.

Maybe so, but we should stick to one set of terms, and as an earlier
email discussion, the group agreed on the use of proactive and reactive.
(at least implicitly).

"planned" still sounds like "provisioned" to me, but that's just my 
connotation.

> 
> 
> > p7: I am not comfortable with the definition of Seamless, 
> in that if it is
> > really simply
> > the combination of smooth and fast, then it is already 
> being done in MIP. I
> > see
> > Seamless as being handover with no (discernable) drop in 
> QoS. This is both
> > semantically and practically different from smooth+fast.
> 
> Actually, if we then start using "seamless", we have to 
> specify whether we
> mean "mobileip-seamless" or "seamoby-seamless" because the term has a
> "well-known" meaning in mobileip.
> 
> We would assume that "being done in MIP" means "being tackled 
> in mobileip WG",
> i.e., refers to the fast handover proposals. (nevertheless, 
> the fact that
> something is being done in mobileip means extensions to MIP 
> that are not
> necessarily straightforwardly applicable to seamoby)
> 
> Would we need another handover type then to include the idea 
> of supporting QoS.
> So, a "QoS (and/or context) aware" handover?

*sigh*. The result of approaching mobility incrementally, from the core
to the edge. Do we "really" need 5 types of handover at the IP layer?
(in addition to soft, hard, etc., etc. at L2).

IMHO: we are the Seamless Mobility working group, and we get to
define what we mean by seamless. since our definition is an enhancement
to the MIP definition (and actually is a new service, not just fast +
smooth),
I don't see a problem, as long as we clearly state what seamless means
to us.

> 
> > p.7: You have introduced the concept of "context aware". I 
> don't think we
> > need yet
> > another handover type. In my mind, context aware was part 
> of seamless. Now,
> > given your definition of seamless, yes, there is context 
> that goes beyond
> > smooth+fast,
> > and indeed goes beyond sustained QoS. Of course, we can 
> define SeaMoby to be
> > seamless + context aware, but now we have a 5 types of 
> handover (including
> > the
> > non-smooth, non-fast, non-context aware case). Would it not 
> be better to
> > define
> > seamless as being context aware? Or, even better, as being context
> > sustaining?
> >
> 
> I can see that we have two types of definitions for seamlessness:
> 
> "Cmless"=seamless+context+everything
> 
> or
> 
> "Cmless"=fast+no-packet-drops
> 
> Since the MIP people have already a definition for seamless, 
> I don't think we
> should make a new one, but perhaps define a new type that 
> includes the notion of
> sustaining the QoS. Would "QoS (aware) handover" be a bad term?

See above....

> 
> > p8: I don't want to open a discussion of paging on this 
> mailing list, so as
> > a short note
> > to be taken to the paging mailing list, I don't believe 
> that paging itself
> > should do all
> > that you imply. There should be an intermediate stage 
> between a paging
> > wake-up and
> > establishment of a SAR.
> 
> True. But I'm not the right person to comment on that issue. 
> Anyone want to add
> more insight to this?
> 
> >
> > p8:, section 2.5: The distinguishment you make between user 
> and personal
> > mobility
> > seems to have more to do with whether push applications are 
> possible. From
> > the appendices,
> > I gather that the definition came from the telecom arena, 
> and is biased (or
> > limited)
> > accordingly. Also, the essence of this definition seems to 
> be tracking of
> > the user, which
> > is outside the scope of SeaMob.
> 
> Yes, we tried to emphasize that these are defined in order to 
> be able to
> describe what is not in scope (L2 handover and similar might 
> also be augmented
> with such remarks).
> 
> > Regards
> > Gary
> >
> 
>