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

From: "Gary Kenward" <[email-masked]>
Date: Tue, 3 Jul 2001 13:17:52 -0400

Cedric:

> -----Original Message-----
> From: Cedric Westphal [mailto:[email-masked]]
> Sent: Tuesday, July 03, 2001 11:52 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: Re: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing
> 
> 
> 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.

This is not true. I simply do not understand where you see this "exclusion".
You are basing your assessment not on the current definition in the
requirements, but on the email exchanges that have been going on.
Personally, my preference
(as I have stated many times) is not to tie ct only to an initiating event
and
to define the completion in terms of a performance requirement.

The current definitions are not perfect. They have been word smythed many
times, and perhaps should be again. I say perhaps, because it is not clear
to me that there is any simple model for ct that will meet everyone's
expectations.
This is one of the reasons that the definitions are as vague as they are.

Below is the heart of the definitions as they currently exist in the draft.
Please explain to me, where in the first paragraph does it say that anything
about the "arrival of the packet at the AR". Proactive is initiated by some
"early warning" event, exactly what event, is tbd and very system dependent.

So much so, that some systems will not provide this early warning and 
the only mode for ct will be reactive. Reactive is initiated by 
a handover event. In some systems, the start of a handover will be available
at L3 for ct, in other systems, other events, such as "link establishment",
"route update", or "first packet arrival", may have to be used. 

   With proactive context transfer, the context is made 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.
   
   With reactive context transfer, the context is made available to
   an AR when the need is imminent. The implication here is that the 
   initiation of a handover, or some event soon after initiation,
   triggers a reactive context transfer. Depending upon the network
   configuration, the MN's velocity and the behaviour 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. 

> Such CT would be neither reactive, nor proactive. It would occur for
> instance
> if some accounting QoS context is transferred after the hand off
> is completed, whereas all the QoS configuration was transferred before.

And if the QoS configuration includes metering information? What you
describe
about, is to me, a two phase proactive ct (actually probably m-phase,
depending
on how many separate ct transfers you do).
 
> 
> 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 

Proactive and reactive cover the cases you cite, and are actually more
comprehensive in their coverage then your definitions for your cases omit a
number of scenarios. We could enumerate each scenario, but it *was* hoped
that
this would be part of the design process, not the requirements process.

The requirement, btw, is that the ct protocol support both modes, which
means that
the design must support both modes. The requirement explicitly states that
the use
of proactive is optional. The objective is to have one ct protocol design,
not a ct
protocol for each envisioned application.

   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.

> combination of
> these two modes is described as
> an unstable situation, or a fall back mechanism. This is what 

??? Ok, let me try it this way: the network does its best to prepare
candidate
ARs for a possible handover of an MNs traffic. It does whatever it can do in
advance simply to keep the actually work load to be done during handover to
a 
minimum (this is proactive). However, in the mean time, the MN moves around
the corner of a building in the canyons of NYC, and *boom*, the MN is
illuminated
by a completely different cell, with no warning. Now, for arguments sake, 
imagine that the new cell is connected to a different AR. Guess what? All
the
preparation done by the network is for naught, and the network must "react"
to
the new situation. 

In short, no matter how you phrase it, the network must *always* be able to
"react"
to unexpected changes in the forwarding path. 

> I disagree
> with.
> It could be per design that the CT is initiated before the 'arrival of
> packets at target AR'
> and completes afterward.

Fine with me. Not an optimal design, but this is going to happen. Again,
the current definitions do cover this. Perhaps there is specific wording
in the current requirement which you would like changed?

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

Nope. I will not agree with using the word "soft", and I do recall
from previous discussions that there are others that agree.

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

Note, in case it has slipped by, proactive and reactive are NOT two phases
of ct. They are non-exclusive *modes* of ct.

> can be transferred 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].

We clearly have a newly identified requirement for "non-critical" context 
transfer (e.g. some suggest accounting info). IMHO, this is already
covered, however, I see no problem in extending the current definitions 
to be more explicit. I do not see that it is justification for starting
up with new definitions.

Gary

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

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 04 Jul 2001 00:24:01 -0700

Gary:

I read your reply, and I have the feeling that you are trying to
convince me that
proactive and reactive cts are indeed required. I think you are missing
my point.
First, for the record: I an convinced both proactive and reactive ct are
required,
and the definition proposed in this issue #4 are satisfying in this
respect. They
are necessary. Agreed. They are not sufficient.
I am not going to comment point by point, I don't have time for this,
but sum up:
-in a previous mail, you said Rajeev's definitions (that you attributed
to Pat) were
good for you.
-they are good definition for proactive and reactive. They do not
consider a mixed situation,
initiated prior to arrival and completed after.
-the draft mentions the support of only proactive or reactive. The draft
as well prohibits
a mixed situation. A proactive ct that completes after whatever event is
a failed proactive ct.
It is a proactive that turns into a reactive (or should a fresh reactive
ct be initiated if the proactive
ct does not completes before the event, not so clear in the draft).
There was not much
point to comment before hand, since, as you say, the draft is ambiguous,
and could be read any way.
But since the clarification issue has been raised, we should address its
consequences.

Please consider the situation where MN at some point in the future  will
go from oldAR to
some identified newAR. I have this context that I want to transfer.
However, it is of no critical value
to the MN at newAR. I have the choice of: (a) proactive: I start
transfering now, and pray it
is established at newAR before (draft quote: 'it is required to forward
the first packet arrival
in the MN's traffic', new definition quote: 'the arrival of MN's packet
at target AR). (b) reactive:
I wait (new definition quote: 'subsequent to the arrival of MN's packet
at target AR) until
(draft mentions: 'initiation of a handover or soon after initiation').
Please explain to me why, since I have no critical deadline, I should
still make a choice between
(a) or (b), that is, to simplify (a) ensure that all my context is
transfered before handoff, or
(b) wait until I handoff to transfer. Where is (c): I take a leisurely
transfer around the handoff,
I start before, but take it easy, dude, whenever I get there is when I
get there.
You might see this as a terminology issue, (what do you call (c) since
it is not proactive nor reactive).
I think it is more a requirement issue. If the requirement draft
specifies (a) and (b), does not
mention any other possibility, explains that if (a) fails, then use (b)
as the only choice of combined/
mixed/soft ct, then it seems to imply that it excludes (c).
I agree with (a) MUST be supported, (b) MUST be supported, tell me why
(c) SHOULD NOT
be supported as a requirement?
Thanks,

Cedric.