Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 18 Jul 2001 17:35:54 -0500

Cedric,

Shame on the DT, for having complete mutual understanding that both pro and
reactive
use the same procedures :) that is why we did not object to the word "mode".

If you have any suggestions, bring it on :)

Madjid

-----Original Message-----
From: Cedric Westphal [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 7:24 AM
To: Henrik Levkowetz; [email-masked]
Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive

Henrik,

let's not argue, since we agree. I just replied to your posting for
clarification.
Still, there are _eight_ mentions of the word mode in the current
requirement
draft, and _all_ the sentences in the proposed words that include the word
mode are in the current draft. Nobody objected to these 8 mentions earlier.
Nobody posted an issue saying: 'modes' are bad. So I hope your understand
my surprise, and my reply. Am I wrong in assuming that words that have been
accepted for several months are satisfying the working group consensus?

Cheers,

Cedric.

Henrik Levkowetz wrote:

> Cedric,
>
>         Your are quite right in that mode may be used more generally, as
it was in the
> introduction sentence. This is not what I object to.  It is the much more
specific
> usage and examples at the end of the text which I object to, as they
actually seem
> to require two separate, different, modes of operation.

>         I'm not in any way particular about the specific wording I
proposed, any wording
> that does not enforce two modes would be Ok; I simply submitted text as
the decent
> thing to do when proposing a change. If you don't like it, different words
could
> be just as fine.
>
>         However, if you don't mean to require that the protocol has two
separate,
> different modes, I believe that the text will have to change somewhat. I
understand
> the way you wish to use mode, but the current text does not clearly read
in that
> manner -- quite the contrary, actually, which is why I commented in the
first place.
>
>         Regards,
>                 Henrik
>
> Cedric wrote:
> >
> > Henrik,
> >
> > thanks for the comment. One general reply, before more specific ones in
line.
> > You are concerned about something that was present in earlier versions
of the
> > requirement draft, and that did not raise any issues back then. The
introduction
> > sentence in section 4.5 of draft-ietf-seamoby-ct-reqs-00.txt is:
> > 'it is useful to consider two modes of operation'. Nobody objected to
that. People
> > discussed at length what those modes were, but never the term _mode_.
> >
> > So why discuss something that had been accepted? If I hear where you
come from,
> > I'd say there is the new multi-phase req that induces changes (so now
there is the
> > added 'non exclusive', to underline that both modes can work
cooperatively in the
> > same ct if need be). Other cautionary words should be in that
multi-phase req.
> >
> > Going through your suggestions, you try to replace 'mode' by 'ability'.
I disagree
> > with this. A mode is a way of doing things (how do you attempt ct?), an
ability is
> > the capacity of doing things (can you achieve this ct?), these are
different notions.
> >
> > A little bit more in-line.
> >
> > Henrik Levkowetz wrote:
> >
> > > Cedric, Gary
> > >
> > >         I find the background explanatory text very good but when you
get
> > > into describing the way the protocol will work, I see an assumption
> > > sneaking in which I don't agree to, namely that the protocol will need
> > > to have two _modes_ of operation.
> >
> > For sure, we agree, and I personnaly did not
> > see or intend the implication that you see. I think the very first
sentence
> > ('two complementray, non exclusive modes of operation') is clear enough
> > to dispell any doubt about getting locked into one _mode_. There's also
> > a paragraph talking on how proactive evolves into reactive if need be.
> >
> > > Maybe it will, or maybe we will be
> > > able to define / design the triggers and handling at the destination
> > > in such a way that there really will be only one mode. But I think
> > > it's premature to imply two modes, ... maybe you didn't really mean
to?
> >
> > To tell you the truth, maybe we don't understand mode the same way. Let
me
> > give a picturesque, snow-plowing the driveway kinda example:
> > a car transmission might have a sporty mode and a comfort
> > mode. Marketing guys in Detroit did the requirement: we must support
sporty,
> > we must support comfort. Do engineers build two different cars? No, it's
just
> > a switch on the dashboard: up, sporty, down, comfort.
> > My point is, a _mode_ is not a _protocol_.
> >
> > >       Anyway, I've suggested revised text inline, below.
> > >
> > >         Best,
> > >                 Henrik
> > >
> > > >
> > > > Hey,
> > > >
> > > > Gary and myself have worked on a new proactive/reactive paragraph
> > > > to explain requirements 4.4/4.5 and solve Issue #4, while keeping
the
> > > > same terminology.
> > > > Here it is, please comment, thanks,
> > > >
> > > > Cedric.
> > > >
-------------------------------------------------------------------------
> > > >
> > > >
> > > > 4.4 The context transfer framework MUST support proactive context
transfer.
> > > >
> > > > 4.5 The context transfer framework MUST support reactive context
transfer.
> > > >
> > > >    It is useful to consider two complementary, non exclusive
> > > > modes of operation for context transfer:
> > > > proactive and reactive.
> > > >
> > > >    The context transfer process is said to be proactive when the
required
> > > > contexts are requested to be in place at the target AR  prior to the
arrival of
> > > > MN's packet
> > > > at target AR.
> > > >
> > > >    With proactive context transfer, the idea is to make the context
available
> > > > to an AR before it is needed. This means that the context is
> > > > available at the AR before it is required to forward the first
> > > > packet arrival in the MN's traffic. Proactive context transfer is
> > > > coupled to mobile handover only by the requirement that the context
> > > > be in place before the handover of the MN's traffic is complete.
> > > >
> > > >    The context transfer is said to be reactive when it is not
proactive.
> > > >
> > > >    The idea is that in a reactive context transfer, no guarantee is
made as to
> > > > when the context will be in place at newAR. The context transfer
process reacts
> > > > to the handover, but has no control over or knowledge of the
handover to ensure
> > > > that it is in places before the arrival of MN's packet at the target
AR.
> > > > Reactive context transfer is coupled to mobile handover only by the
requirement
> > > > that some handover event is triggering the reaction. Reactive
context transfer
> > > > completes as soon as possible, but its completion is independent of
the handover
> > > > process.
> > > >
> > > >    Depending upon the network configuration, the MN's velocity and
the behavior
> > > > of the mobility solution, a reactive context transfer may or may not
complete
> > > > quickly enough for the new forwarding AR to provide a consistent
service to
> > > > the first packets of the re-directed traffic.
> > > >
> > > >    In many situations there is no forewarning available of a
handover
> > > > and context transfer must be initiated simply because the
> > > > re-direction of the MN's traffic is in progress and the AR needs the
> > > > forwarding context immediately. Because of the physical constraints,
> > > > these situations can  never be completely avoided. Thus, if context
> > > > transfer is to be  performed at all, the fundamental mode of
operation
> > > > must be reactive.
> > >
> > > .................................................. Thus, if context
> > > transfer is to be performed at all, its fundamental function must be
> > > reactive context transfer.
> > >
> >
> > I understand what you are trying to do, but saying 'the fundamental
function of
> > ct' replies to the question 'what is ct' (the fundamental function of ct
is to
> > transfer
> > context), and this addresses the question 'how'.
> >
> > >
> > > >
> > > >    The proactive mode of context transfer is an attempt to further
> > >
> > >    The ability to transfer context proactively is an attempt to
further
> > > ...
> >
> > an ability is not an attempt.
> >
> > Henrik, I hope that this helped alleviate your concerns,
> > best regards,
> >
> > Cedric.
> >
> > >
> > >
> > > > reduce any disruption of the service provided to the MN's traffic by
> > > > making the context available to an AR prior to it being needed for
> > > > forwarding. This implies that some network event will occur at the
IP
> > > > level to indicate the potential for a handover, prior to the
handover
> > > > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > > > trigger a proactive context transfer if there is confidence the
context
> > > > transfer can complete before the arrival of MN's packet at the
target AR.
> > > > There can be no guarantee that this event will occur or that this
confidence
> > > > will be acquired, and thus, a reactive context transfer is
> > > > always required as a contingency.
> > > >
> > > >    This also means that a context transfer that begins in proactive
mode
> > > > may, as a result of the MN moving or other changes to the wireless
> > > > environment, be required to complete in reactive mode.  If the
target
> > > > AR stays the same, then the same proactive context transfer attempt
> > > > should evolve into a reactive context transfer attempt.
> > >
> > >    This also means that a context transfer that begins as a proactive
transfer
> > > may, as a result of the MN moving or other changes to the wireless
> > > environment, be required to complete as a reactive transfer.  If the
target
> > > AR stays the same, then the same proactive context transfer attempt
> > > should evolve into a reactive context transfer attempt.
> >
> > >
> > > >
> > > >    As the proactive mode of context transfer is an enhancement,
there may be
> > > > situations where the reactive mode is considered a sufficient
solution.
> > > > While it is required that the context transfer protocol support
proactive
> > > > mode, its use is optional.
> > >
> > >    As proactive context transfer is an enhancement, there may be
> > > situations where reactive transfer is considered a sufficient
solution.
> > > While it is required that the context transfer protocol support
proactive
> > > context transfer, this ability may not always be implemented or used.
> > >    <<<The last sentence limps a bit, I think. Maybe you'll find
> > >       a better formulation that doesn't go into Modes. /Henrik>>>

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 23 Jul 2001 11:58:38 -0400

At one point, many, many moons ago, I tried to capture this issue
by suggesting that "the context essential to IP packet forwarding must
be in place". In my mind, this is the essence of the multi-phase ct
proposal - there is context that is required to support the forwarding
service for each packet, and there is other context that is important,
but not as imperative.

Anyhow, this is how I see the two concepts of "proactive/reactive" and
multiphase ct relate.

Gary

-----Original Message-----
From: Theo Pagtzis [mailto:[email-masked]]
Sent: July 16, 2001 13:46
To: Emil Sturniolo
Cc: Cedric Westphal; Pat Calhoun; Kenward, Gary [WDLN2:AN10:EXCH];
seamoby

Hi Emil,

    While I would agree with the terminology over proactive context
transfer, I would have to disagree on the atomicity of tranfer with
respect to proactivity. Proactivity must not require that all context is
transfered to the new point of attachement. This is bound to be too
costly should the selection decision of the new CAR misses the correct
candidate; this is bound to be the case a lot until...something 'else' is
in place. More on that 'else' later.

The transfer of context must be bound by the context constituents that
are sufficient and necessary for the node to transit over a proactive
transition mode. This implies partial context existence in the new
candidate points of attachement. Partiality must not mean that something
critical for seamlessness is not in place in terms of context at the
CARs. Thus partial context transfer over proactive transition mode(s)
must imply a totality of context necessary to effect seamlessness.
Depending on what is considered as a seamlessness factor in each context
ontology, then the totality and partiality over transfer of a discrete
number of constituents in new CARs is defined accordingly.

I would like to expand the set of transition modes to the CT requirements
document by adding an extra transition mode. It can be found in
draft-pagtzis-mobileip-proactivev6-00.txt or ps file.

This is the transition mode of "forward reactive handoff". I personally
consider it as equally important since it provides the intermediate step
between a pure reactive and a pure proactive handoff.

I would appreciate the view of the constituency on this transition mode
for the purposes of context transfer.

Theo

UCL/ Mobile Systems

Emil Sturniolo wrote:

> Hi folks,
>         I just have one observation. From reading the new text:
>
> "This means that the context is available at the AR before it is
> required to forward the first
> coupled to mobile handover only by the requirement that the context be
> in place before the handover of the MN's traffic is complete."
>
> My interpretation of this is that a "proactive context transfer" must
> be totally completed prior to HO. If one considers a multi-phasic
> transfer, and only enough context is transfer proactively to allow
> packet forwarding, but other ancillary information is subsequently
> communicated, I believe from the current definition that the
> completion of this transfer is deemed a "reactive process". I am fine
> with this distinction,  but I would like to see it be specifically
> stated rather then just implied. Alternatively, we could change the
> text slightly to account for this case and still allow it to be a
> completed within the scope of a proactive transfer. Suggested text:
>
> "This means that enough of the context is available at the AR before
> it is required to process any of the MN's traffic. Proactive context
> transfer is coupled to mobile handover only by the prerequisite that
> elements of the context that enable packet forwarding be in place
> before the handover of the MN's traffic is complete."
>
> Comments?
>
> Cordially,
> Emil Sturniolo
> [email-masked]
> www.NetMotionWireless.com
> 330-723-9099
> 330-461-0326 - Mobile/Voice Mail
> =====================