Subject: RE: [seamoby] Reactive context transfer

From: "Gary Kenward" <[email-masked]>
Date: Fri, 15 Jun 2001 13:57:56 -0400

Charlie:

 For us, it is unacceptable that CT should be dependent upon
some layer 3 messaging from the MN. Over the air transit latencies
are just too great, and we don' see the value. I think here we
simply must agree that we have different views of the world.

 This whole issue was discussed at great length, and it was
clear then that there was no "right" approach. We decided then
that we would abstract out the initiating event - some called
it a trigger - and that would allow for different networks and
different vendors to define the approach they like the best.

 Who triggers context transfer is not relevant, unless we believe
we are going to build the trigger into CTP as a signalling message.
There was a long debate, and it was decided very early on that
it was not necessary to build this into CTP. That does not
mean that this approach is excluded from the mobility solution, nor
does it mean that an MN message could not trigger CT indirectly. It
simply means that CTP will not include an MN to AR message.

 You can refer to the archives if you question this, in particular,
the conference call meeting minutes. 

 At the moment, I would suggest strongly that we retain that decision.
It allows both camps to work on their preferred solution. More importantly,
it would allow us to move forward. 

 What you are proposing is to return to the discussions of six months ago.
This would be unacceptable to me, for sure, and I suspect others engaged 
with this process would also be very frustrated.

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Friday, June 15, 2001 1:01 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: [seamoby] Reactive context transfer
> 
> 
> 
> Hello Gary,
> 
> > Gary Kenward wrote:
> 
> >        .......                   We did discuss how CT was to be
> > initiated, and agreed that there would be no explicit 
> signalling from
> > the MN (not at least as far as CT was concerned).
> 
> I would consider this as wholly unacceptable, except that in your
> next paragraph you state:
> 
> >   The definition of reactive CT (read the problem 
> statement)has to do with
> > the order/timing of events, not with where the initiating 
> event comes from.
> 
> So then I started to wonder about how one might define "reactive" to
> make the previous sentence come true.  But, the word "reactive" does
> not occur in draft-ietf-seamoby-context-transfer-problem-stat-01.txt.
> No help there.  I did find some redefinition of "reactive" in
> draft-hamid-seamoby-ct-fwk-00.txt, but that document was, I believe,
> not the result of design team discussions.  In fact, I have some
> other comments on the latter document, but for now I would just like
> to suggest that it should not be taken as relevant to the current
> discussion about reactive context transfers.
> 
> That puts me back to square one.  From that standpoint, I would like
> to suggest that the context transfer problem statement needs to
> very clearly define the following concepts:
> 
> - Network-initiated context transfer, for which the access network
>   tells the mobile where to go
> 
> - Mobile-initiated context transfer, for which the mobile tells the
>   network where it wants to go
> 
> - Predictive context transfer, for which either the mobile or the
>   network initiates context transfer BEFORE leaving the previous
>   access router
> 
> - Reactive context transfer, for which either the mobile or 
> the network
>   initiates context transfer AFTER the mobile arrives (establishes
>   a link) at the new access router.
> 
> 
> I like the word "predictive" for several reasons:
> 
> - It has exactly the right meaning, and even connotes that caution
>   is necessary because not all predictions come true
> 
> - In contrast to some other alternatives one often hears, it is
>   a word that one can find in the dictionary.
> 
> Regards,
> Charlie P.
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 15 Jun 2001 11:11:27 -0700

Hello Gary,

> simply must agree that we have different views of the world.

Maybe we're not so far apart after all.  Of course I agree that
we should have the possibility to do context transfer without
requiring the mobile node to trigger the process.  I'm just
holding out for the possibility that the mobile node CAN trigger
the process in some circumstances.  For instance, it would probably
be just fine over 802.11, even if it's not advisable over some
cellular media.

> different vendors to define the approach they like the best.

Exactly.  Thus, I claim we aren't so far apart.  But, some of the
allowable choices should include allowing the mobile node to
initiate the process of context transfer.

> simply means that CTP will not include an MN to AR message.

Again, just because context transfer CAN be accomplished without
a trigger from the mobile node in SOME circumstances, does not mean
that the mobile node should be disallowed from supplying the trigger
in OTHER circumstances.  Thus, I agree with the second and third
sentences, but it seems pretty clear that we can ALLOW such a
trigger indication without dragging down the rest of the protocol.
Thus I am asking for reconsideration of the 4th sentence, and I
don't see any downside at all.

> the conference call meeting minutes.

That's raising the bar pretty high for my participation in this
particular discussion.  Would it be O.K. to ask that you respond
just to my points in this e-mail?

> with this process would also be very frustrated.

Well, from the e-mail I've seen so far, it looks like there may be
frustrations on both sides.  Moreover, to accomodate those who wish
to allow mobile-node triggering, I don't think would cause any
discomfort to those who want to have network-initiated transfers.
So why not?

Regards,
Charlie P.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 11:17:15 -0700

Charlie,

Based on your comment below, it doesn't sounds like you are stating that
a CT MN->AR message is needed, but rather that a L2 trigger that would
cause CT MAY be generated by the mobile.

If this is true, then I believe that we are *all* in agreement, and if
so, may I ask what in the spec could be changed to reflect this agreement?

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 15 Jun 2001 12:09:01 -0700

> cause CT MAY be generated by the mobile.

Rajeev: I am sorry, I don't know how we can say that we can rely on a L2 trigger
from the MN to cause CT. This could work on some links but not on others. It has
got to be an IP message, for us.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 15 Jun 2001 12:44:05 -0700

Hello Pat,

Apparently,

> Pat Calhoun wrote:

.... something!  and, then ....

> so, may I ask what in the spec could be changed to reflect this agreement?

I see that you have sent some e-mail on this subject, and I reckon
I am in agreement with you, but I didn't see your original e-mail.
Maybe it's stuck on some spool somewhere funny.  I got this from
Rajeev's reply.

Just to be clear, I think there should be an _optional_ network-layer
(or above) message to trigger context transfer, which can be sent
by the mobile node in cases where deemed necessary.  Of course, for
systems which support a layer-2 trigger (and the necessary inter-module
communication), the layer-3 message might be unnecessary.

Pointing out the obvious, for systems that don't need the layer-3
trigger, the information that it would have provided needs to be
sent within some part of the network-initiated control messages.

Of course we don't know what information is involved yet, but it
would presumably have to do with identifying the appropriate
microflows for which context needs to be transferred, along with
information about how to verify that the appropriate mobile node
is targetted to receive the part of the context information that
it might need (e.g. for header compression).

Regards,
Charlie P.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 18 Jun 2001 07:14:34 -0700

> got to be an IP message, for us.

... and a Mobile IP message from the MN to the attendant is not sufficient (e.g.
Binding Update)? Does it really need to be a CT protocol message?

PatC