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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 3 Jul 2001 16:55:45 -0500

Cedric,

I actually liked the cease fire, for the past three months we have 
opened the proactive/ reactive issue many times.
We talked about timing, reliability and other things,
 and time and after time we came back to the same discussion:

 CT's timing and its relation with handover

The issue has not been resolved, since different people have
different mental image about the sequence of events during
Handover and that impacts the way they want to see CT happen.

As I said many times it does not matter what scenario is called reactive or
whether reactive is post-A or post-B. 

The requirements need to consider the events, cover all the scenarios and
make CT as good of optimization as possible and remember that
this is supposed to be optimization over the no-CT case.

The nomenclature is less important at this point.

The last round of email discussion has concluded that we should
discuss this face to face to prevent going into cycles and having
people staring at their monitors for new proactive/ reactive that
might pop up on the list any minute.

So please lets not breach the truce, each one of us would have more
time to think about what we want out of CT in the meantime :)

Madjid

-----Original Message-----
From: Cedric Westphal [mailto:[email-masked]]
Sent: Tuesday, July 03, 2001 2:55 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Gary Kenward'; '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 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: Kulwinder Atwal <[email-masked]>
Date: Wed, 4 Jul 2001 05:55:44 -0400

Consider a Network-Initiated Context Transfer (leaving out the Acks):

The Network Initiator could be any entity including: ParentAR, oldAR, newAR,
MN.

Step 1:

 MN	[oldAR]<---- CT Request MSG -----+
 |       |                             |
 |       |                             |
 |       |                             |
 |       |                            [ParentAR]<- Common RT Change/CT MSG
--[Network Initiator]
 |       |                             |
 |       |                             |
 V       |                             |
      [newAR]<--- New MN packets ------+

Step 2:

 |	[oldAR]--------------------------+
 |       |                             |
 |       |                             |
 |       |                             |
 |    Context                          [ParentAR]---------[Network
Initiator]
 |    Transfer                         |
 |       |                             |
 V       V                             |
 MN	[newAR]--------------------------+

You will notice that it is impossible for the Context Transfer to happen
BEFORE the Route Change, or the arrival of new MN packets.  

Putting the onus on CT to complete before handover is incorrect.  The
network must delay route change until the CT has a chance to get started to
increase the chance that the CT will complete and new packets arrive _near_
the same time.  The 'correct' delay is network specific.

If you assume FMIPv6, then you are creating an FMIPv6 specific solution.
The Care of Address could be held at the ParentAR.

Consider an MN-Initiated post-connection Context Transfer (leaving out the
Acks):

Step 1:

 	        [oldAR]<-------------------------+
 |               ^                             |
 |               ^                             |
 |               |                             |
 |            CT Req                           [ParentAR]--------------
 |               |                             |
 |               |                             |
 V               |                             |
MN RT/CT MSG->[newAR]---- Route Change Req --->+

Step 2:

 	[oldAR]--------------------------+
         |                             |
         |                             |
         |                             |
      Context                          [ParentAR]---------
      Transfer                         |
         |                             |
         V                             |
 MN	[newAR]<--- new MN pakcets ------+

In this case the network should introduce less delay to increase the chance
that new MN packets and context arrive _near_ the same time.

It is not up to the Context Transfer Protocol to ensure any 'timing
requirements' such as 'proactive' must complete or should complete before
handover.  This is a network responsibility.

How can CT possibly know what the network architecture is?

Again, I believe the linkage between Context transfer and Handover
completion needs to be removed.

- Kulwinder.

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Tuesday, July 03, 2001 5:56 PM
> To: 'Cedric Westphal'; Nakhjiri Madjid-MNAKHJI1
> Subject: RE: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing
> 
> 
> Cedric,
>

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 4 Jul 2001 09:38:49 -0400

Kulwinder:

> From: Kulwinder Atwal [mailto:[email-masked]]
> Sent: Wednesday, July 04, 2001 5:56 AM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric Westphal'
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; 
> [email-masked]

Why? It is not only possible, but the equivalent of ct is performed today
in 2G cellular networks. There seems to be some presumptions built into
your model which I prefer not to guess at, perhaps you could explain 
why this is impossibility exists? 

*snip*

Gary

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 4 Jul 2001 10:35:50 -0400

Does not the CT arrive after the first packet, if the CT cannot start until
the CT req has arrived from the ParentAR?
 
- Kulwinder.

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 9:39 AM
To: 'Kulwinder Atwal'
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing

Kulwinder: 

> From: Kulwinder Atwal [ mailto:[email-masked]
<mailto:[email-masked]> ] 

*snip* 

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 4 Jul 2001 11:28:12 -0400

Well, no, CT does not arrive after the first packet. Not if your aiming
for seamlessness and you attempt to be proactive.
 
This concept of a "ParentAR" is new to me, as far as I know, it is not 
required for ct. Regardless, ct can start as soon as the network determines
that there is a potential for handover to the receiving AR (aka "newAR",
although
I dislike this term as it implies a singular AR is involved in receiving
context, and 
that this "newAR" will be the handover target, which it may or may not be),
and
generates an L3 event to inform the ct peer to exchange context (somehow -
tbd
if and when we get around to designing a protocol).
 
The assumptions behind your scenario are valid for certain networking
solutions.
But, they are not generally applicable. Some networks know a lot about what
is
happening to the MN at the PHY/MAC level.
 
Regards,
Gary

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 10:36 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; Kulwinder Atwal
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing

- Kulwinder.

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 9:39 AM
To: 'Kulwinder Atwal'
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing

*snip* 

Gary

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 4 Jul 2001 12:01:10 -0400

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 11:28 AM
To: 'Kulwinder Atwal'
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing

 
[KA] My point is that it is the network that determines when to start CT.
It is a network's responsibility to determine when to start CT.  And, it is
the network's responsibility to ensure that Handover and CT complete near
the same time.  It is NOT the CT protocol's responsibility to ensure this,
therefore instisting that CT must complete before Handover is not a valid
requirement.  We could just as easily for a particular network say that we
want Handover to complete before CT, and put the requirement into the
Handover Protocol.  The End-User would be just as satisfied.  The ordering
is inconsequential.
 
[KA]  It is network specific whether to start CT first, or Handover first.
It absolutely does not matter which finishes first.  Just as you can provide
examples of when Handover happens first,  I can provide examples where the
reverse is true.
 
[KA]  Rather than have people say, " Oh, but we really need CT to happen
before handover.  So much so, that we must have it as a MUST requirement",
I would like these same people to show what terrible thing would happen if
the order were reversed by a few milliseconds.
 
[KA] We are all interested in having CT happen quickly, so I really don't
see the reason for this unnecessary sequential linkage in a requirements
document.

 
Regards,
Gary

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 10:36 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; Kulwinder Atwal
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing

- Kulwinder.

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 9:39 AM
To: 'Kulwinder Atwal'
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing

*snip* 

Gary