Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing

From: "Gary Kenward" <[email-masked]>
Date: Tue, 3 Jul 2001 09:59:09 -0400

Cedric:

> -----Original Message-----
> From: Cedric Westphal [mailto:[email-masked]]
> Sent: Tuesday, July 03, 2001 3:55 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; 
> [email-masked]
> Subject: Re: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing
> 
> 
> Sorry to breach the truce, but here are some comments:
> 
> Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> > I suggest we leave this as an open issue, until we meet in IETF.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Gary Kenward [mailto:[email-masked]]
> > Sent: Friday, June 29, 2001 10:28 AM
> > To: 'seamoby'
> > Subject: [seamoby] Issue #4: Clear, unambiguous definitions missing
> > Sensitivity: Confidential
> >
> > In the interest of moving the requirements forward, I 
> support the change in
> > the
> > definitions of "reactive" and "proactive' proposed by Pat:
> >
> > Reactive CT: The context transfer process which takes place 
> subsequent
> > to arrival of a MN's packet at the target AR
> >
> > Proactive CT: The context transfer process in which the 
> required contexts
> > are in place at the target AR  prior to the arrival of MN's 
> packet at target
> > AR.
> >
> 
> reactive sounds good to me, but not proactive. There is a 

From your arguements below you seem to support being proactive,
it's all the connotations that have been spun around what proactive
does or not mean that you object to. It's impossible to counter the
tide of popular belief (just look what has happened with "seamless").
Please be assured, there has never been a formal definition of 
"proactive" that included, or implied serialization. Indeed, every 
attempt has been made to avoid this definition. Truthfully, I believe 
that whatever name we chose would end up painted with the same innuendo.

So at this time - if I am correct in my observation that we all do indeed
believe that serialization is a bad thing, but that being prepared for
the actual handover ahead of time is a good thing - we are really involved
in a nomenclature debate. From my point of view this is a waste of
our collective energy, but so be it. Let's pick a word.

"Dynamic" and "static" tends to capture somewhat the attributes of the
context at different phases, but the terms are too restrictive. An early
transfer of dynamic context should be allowed if it enhances handover.
"predictive" doesn't work for me either, as it implies that ct is involved
with some sort of inductive logic; while there may be an entity attempting
to "predict" which base/AP/AR the MN will appear on next, it is not part
of ct.

So that leaves? Well, how about prophylactic? Hmmm, unlikely to pass the
scrutiny of the IESG for all the snickers it would incite from the just-
out-of-high-school crowd.

We are deep into trying to define how the protocol should work, when we
are supposed to be finishing off the requirements document. Maybe the answer
is to avoid the use of catch phrases, and simply write requirements that
state what it is that we want to accomplish.

Cheers,
Gary

> consensus for support
> for several phases in CT. So it seems that the term 
> 'required' needs to be
> clarified.
> In the CT phases discussion, the talk is about priority. Some 
> contexts are more
> important than other. Which is true, but mostly some contexts 
> are more time
> sensitive
> than other. Some accounting contexts, which some operator 
> would argue is _very_
> important, can arrive later, after the arrival of MN's packet 
> at new AR. This
> requirement denies this possibility.
> 
> Solutions: 1) define a static context (configuration state) 
> and a dynamic
> context (accounting
> state). Static context is what has to be transfered before 
> the arrival of MN's
> packet
> at target AR. Replace 'required' in your definition by 
> 'static', or 'config'.
> Dynamic is what
> can be transfered later to fill in the blanks. I have some 
> text on this if you
> want.
> 
> -or-
> 
> 2) one of the issues with proactive/reactive is that it connotes a
> serialization. pro/before, re/after.
> There seems to be somewhat of a consensus as to before what 
> and after what
> (having the
> newAR default router, or having the newAR receiving packets 
> from the MN).
> For instance in this proposal, the whole transfer has to be 
> performed _before_
> (prior in the
> text) the arrival of MN's packet at newAR. Other proposals: 
> pre-handoff,
> post-handoff, same
> thing. Charlie's proposal: reactive, predictive, also same thing.
> On the other hand, CT can be initiated before/after, and 
> completed before/after.
> So, if you take
> away the initiated after/completed before, you still need at 
> least THREE terms.
> There is also a consensus on reactive: initiated 
> after/completed after. The
> issue is with proactive,
> which means before, and has to cover the CT completed *after* 
> case, which is
> somewhat
> counter-intuitive.
> So here is yet another proposal, which borrows the handoff 
> terminology, and is
> in everybody's
> dictionnary:
> hard CT = reactive CT
> soft CT = a CT in which the transfer is initiated before the 
> arrival of MN's
> packet at the target
> AR. (no mention of completion, covers the initiated before, 
> completed before or
> after case).
> proactive CT= the definition up this mail (covers the 
> initiated before/completed
> before case).
> 
> Cheers,
> 
> Cedric.
> 
> >
> > Since these are "definitions" and not requirements, I 
> assume that there is
> > room
> > for change as we delve into the design process.
> >
> > For what it's worth . . .
> >
> > Gary
> 
>

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 03 Jul 2001 07:29:55 -0700

Gary:

> that whatever name we chose would end up painted with the same

pro-active means to act before. We should agree on that. Now, it seems
that the event answer to 'before what' is: 'arrival of MN's packet at
target AR'.
Fine with me. Thus if you define proactive CT this way, there is an
implicit
requirement that CT is completed before said event. Fine, we are in the
process of defining requirements, and I'd accept a 'proactive CT', as
you
define it.
Then again, why in the universe would you forbid that a CT initiated
before
the 'arrival  of ...' could only complete after. Maybe you don't, but
then don't use
a word that would actually mean this.

> out-of-high-school crowd.

prophylactic? what I object to is any word that starts with pro- or
pre-,
latin root for before, to mean something that does indeed starts before,

but can end after. That's why I like 'soft'/'hard', but am open to
pretty much
anything.
Take care,

Cedric.

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 03 Jul 2001 08:52:11 -0700

Gary,

allow me to rephrase this in a more constructive manner.
In order to clarify the proactive/reactive issue, some definitions were
proposed.
The proposed definitions do meet their goals, and offer satisfying as
well as
intuitive definitions of proactive and reactive context transfer.
Yet, they do exclude a category of context transfers that should be part
of the
CT requirements, namely context transfer that are initiated before the
'arrival
of MN's packets to the mobile node' and completed after such an event.
Such CT would be neither reactive, nor proactive. It would occur for
instance
if some accounting QoS context is transfered after the hand off
is completed, whereas all the QoS configuration was transfered before.

The requirement draft gives the impression that two CT modes MUST be
supported,
one 4.5 proactive, one 4.4 reactive, and these only. The combination of
these two modes is described as
an unstable situation, or a fall back mechanism. This is what I disagree
with.
It could be per design that the CT is initiated before the 'arrival of
packets at target AR'
and completes afterward.

While I agree with these two requirements, I think a third type of CT at
least SHOULD be
supported.

I suggest:
-get rid of : 'It is useful to consider two modes of operation for
context transfer: proactive and reactive.

-add: 4.5 and 1/2, The context transfer framework SHOULD support a
'soft' context transfer.

-after the paragraph 'In many situations, there is no forewarning...'
add:

In some situation, a soft context transfer, namely a combination of
reactive and proactive may be used. Some part of the context
can be transfered before the arrival of MN's packets to the target AR
while the remaining context
is transfered afterwards. This situation may arise when some parts of
the context are more urgent than
other, and should be transfered before the arrival of MN's packet,
whereas there is no such
requirement on the remaing parts of the context transfer. [or add a
pointer to the
multi-phase support requirement].

-replace in the following paragraph: 'This also means that a' by 'A'.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 10 Jul 2001 15:00:25 -0700

All,

I agree with Cedric that the multi-phasic requirement should use
time sensitive, as opposed to urgent or important. I think this
would guide the implementor in a better direction than having to
determine whether a blob is important or not (chances are, they are
all important).

PatC