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

From: "Gary Kenward" <[email-masked]>
Date: Tue, 3 Jul 2001 11:49:47 -0400

*sigh*

From websters:

2 [pro-reactive] : acting in anticipation of future problems, needs, or
changes

It does not say "finish before", "complete before", or anything like it.

"Soft" and "hard" are cellular terms that have much too much baggage. To
begin with, they are strongly associated with L2 functionality (although, to
be precise, soft handover in CDMA is supported by extensive proactive L3
functions). 

Why do you have so much objection to trying to prepare for a handover? This
is what
ct is all about, preparing an AR to accept a handover so that the service is
not impaired by the handover. The fact that there will always be situations
that cannot be prepared for does not mean that preparation is not
worthwhile. 

This is nonsense - let's toss *all* the terms, and focus on the issue, which
is to develop a ct that enhances handover.

Gary

-----Original Message-----
From: Cedric Westphal [mailto:[email-masked]]
Sent: Tuesday, July 03, 2001 10:30 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]
Cc: 'seamoby'
Subject: Re: [seamoby] Issue #4: Clear, unambiguous definitions missing

Gary: 
Gary Kenward wrote: 
  
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.
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. 
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.
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. 
  
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 23:58:52 -0700

Gary Kenward wrote:

>
>
> *sigh*
>
> From websters:
>
> 2 [pro-reactive] : acting in anticipation of future problems, needs,
> or changes
>

my own *sigh*. if 'anticipation' is not like it, then what does it mean?

> "Soft" and "hard" are cellular terms that have much too much baggage.
> To begin with, they are strongly associated with L2 functionality
> (although, to be precise, soft handover in CDMA is supported by
> extensive proactive L3 functions).

I don't care about terminology (even htough soft and hard have mostly a
handoff baggage, which
is not bad for ct). that's not the point.

> Why do you have so much objection to trying to prepare for a handover?
> This is what
> ct is all about, preparing an AR to accept a handover so that the
> service is not impaired by the handover. The fact that there will
> always be situations that cannot be prepared for does not mean that
> preparation is not worthwhile.
>

????? do I object to proactive ct? where? preparation is good. Early
bird gets the worm.
I worry you are missing my point though.
Which, even though I don't enjoy it, I will re-explain in the next
email.

Cedric.

> that the event answer to 'before what' is: 'arrival of MN's packet at
> target AR'.
> the 'arrival  of ...' could only complete after. Maybe you don't, but
> then don't use
> but can end after. That's why I like 'soft'/'hard', but am open to
> pretty much
> anything.
> Take care,
> Cedric.
>