Subject: Re: [seamoby] Reactive context transfer

From: James Kempf <[email-masked]>
Date: Fri, 15 Jun 2001 14:41:15 -0700 (PDT)

Rajeev,

How many bytes is the message you have in mind? Add that up to
the bytes I sent out for FMIPv6 handover, divide by the link speed,
and you get yet more latency.

It is simply not acceptable to run up radio link latencies if we
expect to get good real time performance on 3G protocols. 

On WLAN, with better aggregate performance, you can do it.

We *must* have the alternative of triggering the context transfer
at L2.

		jak
		
>Delivered-To: [email-masked]
>X-mProtect: Fri, 15 Jun 2001 12:09:03 -0700 Nokia Silicon Valley Messaging 
Protection
>Date: Fri, 15 Jun 2001 12:09:01 -0700
>From: Rajeev Koodli <[email-masked]>
>To: Pat Calhoun <[email-masked]>
>CC: "Charles E. Perkins" <[email-masked]>, Gary Kenward 
<[email-masked]>, "'seamoby'" <[email-masked]>
>Subject: Re: [seamoby] Reactive context transfer
>
>Pat Calhoun wrote:
>
>> 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.
>>
>>
>
>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.
>
>
>
>> 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
>> On Fri, Jun 15, 2001 at 11:11:27AM -0700, Charles E. Perkins wrote:
>> >
>> > Hello Gary,
>> >
>> > > Gary Kenward wrote:
>> >
>> > >  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.
>> >
>> > 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.
>> >
>> > >  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.
>> >
>> > 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.
>> >
>> > >  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.
>> >
>> > 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.
>> >
>> > > You can refer to the archives if you question this, in particular,
>> > > 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?
>> >
>> > > 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.
>> >
>> > 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: Charlie Perkins <[email-masked]>
Date: Fri, 15 Jun 2001 15:09:56 -0700

Hello Jim,

I can't totally speak for Rajeev, but I'm pretty sure
that no such restriction was suggested.  In my
discussions with Rajeev, our conclusion was that
we wanted the possibility for a layer-3 trigger,
not the requirement for it.  We should be able to
run the protocol predictively or reactively, and
triggered from layer 3 or from layer 2, and initiated
by the network or by the mobile node.

This is doable, and very desirable to have the
same protocol messages for the various cases
insofar as it is possible to do so.

Regards,
Charlie P.