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

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

Henrik:

  I agree with the comments concerning "modes of operation for the
protocol". The original intent was not to imply a modal protocol,
but clearly that has happened. Again, "proactive", and "reactive", are
attributes of the objective: which is context transfer.

  You (indirectly) suggest below that "proactive" and "reactive" are 
"capabilities" of ct. I prefer this term, and suggest that we revise
the requirement to talk about "capabilities" rather then "modes"
or "functions".

  I've added some comments below (indicated by the lines starting with
"**").

Gary

-----Original Message-----
From: Henrik Levkowetz [mailto:[email-masked]]
Sent: July 16, 2001 04:25
To: seamoby
Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Cedric Westphal
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive

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.  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?

	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 agree with the intent of this change, but not the proposed text.
** The fundamental function of ct is context transfer. I think calling
** "reactive" a "function" is worse then suggesting it is a "mode of
operation".

> 
>    The proactive mode of context transfer is an attempt to further

   The ability to transfer context proactively is an attempt to further
...

** Ahh, maybe you have hit upon it here: "proactive" and "reactive" are 
** "capabilities" of ct?

> 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.

** With you up to the last sentence. If the target AR changes, will ct have
to
become reactive also? I do not understand the qualification.

> 
>    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: "Henrik Levkowetz" <[email-masked]>
Date: Mon, 23 Jul 2001 19:58:46 +0200

Gary,

There's a saying in Swedish which goes something like this:
  "Even a blind hen sometimes finds a seed."
i.e. I may have inadvertently hit upon something that makes sense :-) 

A few more words inline, below.

	Best, Henrik

Gary wrote:
>   I've added some comments below (indicated by the lines starting with "**"). 
> 
> Gary 
> 

... <snip>

> ** "reactive" a "function" is worse then suggesting it is a "mode of operation". 

Um, I think you right. If we don't end up implying fixed modes
further down, maybe 'mode' is the best choice here. Or maybe something
with capability, but a good formulation doesn't spring to mind.

> ** Ahh, maybe you have hit upon it here: "proactive" and "reactive" are 

Yes, it does make sense.

... <snip>

>    This also means that a context transfer that begins as a proactive transfer 
> ** With you up to the last sentence. If the target AR changes, will ct have to 

I agree fully. (Note that I haven't touched that last sentence...)

... <snip>