Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)

From: James Kempf <[email-masked]>
Date: Wed, 11 Jul 2001 15:42:09 -0700 (PDT)

Kulwinder,

I was thinking more of whether or not a handoff is even going to happen.
If the HO signaling never occurs, the AR must drop the CT at some point,
unless, as you note, it is so stable (and the amount of state the AR
must cache is well bounded) that it can simply hang on to it.

		jak
		
>From: "Kulwinder Atwal" <[email-masked]>
>To: "James Kempf" <[email-masked]>, <[email-masked]>
>Cc: <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>
>Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,    
      RE: Issue #4)
>Date: Thu, 12 Jul 2001 06:50:55 -0400
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>
>
>----- Original Message -----
>From: "James Kempf" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Cc: <[email-masked]>; <[email-masked]>;
><[email-masked]>; <[email-masked]>;
><[email-masked]>
>Sent: Wednesday, July 11, 2001 6:05 PM
>Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,
>RE: Issue #4)
>
>
>> Ok, then it does seem we agree (or perhaps Gary doesn't?) that
>> there is an ordering on what's needed for nAR to be primed for
>> that first packet. nAR must have the HO signaling and the CT
>> signaling, and if it doesn't have the first, it must wait
>> for the second, and vice versa.
>>
>> IMHO, whether or not that is done by doing the signaling separately
>> (and thus incurs the overhead of maintaining timers on the router)
>
>When a context is 'too stale' is really context dependant, not whether or
>not the HO happens according to some ideal.
>Therefore, the timers I would think would be for things like ROHC
>specifically, but not for static context or CT/HO in general.
>
>In fact, an AR in a private wireless network could hold on to static context
>in FLASH memory and reuse it, since it knows that there are only a few MNs
>in the small private network.  Such an AR would only ever need to request
>dynamic context and authentication.
>
>In general, as Gary has suggested, CT/HO state could just be the subject of
>garbage collection at an implemenation specific interval.
>
>- Kulwinder.
>
>> or together is an implementation decision. I suppose whoever does
>> the MIP binding will determine that.
>>
>> jak
>>
>> >Delivered-To: [email-masked]
>> >Date: Wed, 11 Jul 2001 13:41:41 -0700
>> >From: Pat Calhoun <[email-masked]>
>> >To: James Kempf <[email-masked]>
>> >Cc: [email-masked], [email-masked],
>> [email-masked], [email-masked],
>[email-masked]
>> >Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD
>be ,
>>       RE: Issue #4)
>> >Mail-Followup-To: James Kempf <[email-masked]>,
>[email-masked],
>> [email-masked], [email-masked],
>> [email-masked], [email-masked]
>> >Content-Disposition: inline
>> >User-Agent: Mutt/1.2.5i
>> >
>> >James,
>> >
>> >I believe that there are ways around this. One example is a very
>> >simple MIP extension that is sent stating that a CT is forthcoming
>> >(or may have already been sent). At least, this would be enough for
>> >the receiver to know that it must wait for CT before sending packets
>> >to the mobile.
>> >
>> >PatC
>> >On Wed, Jul 11, 2001 at 01:43:51PM -0700, James Kempf wrote:
>> >> Gary,
>> >>
>> >> >Err, no. That's not what I was agreeing to.
>> >> >Once again, proactive ct should be driven by the initiation
>> >> >event, not the deadline event. It is preferable that context
>> >> >be installed before the traffic arrives at the newAR, but it's
>> >> >not a MUST requirement, and it certainly does not dictate that
>> >> >ho and ct protocols must be synchronous.
>> >> >
>> >>
>> >> I'm not sure I understand. If nAR can't deliver packets unless
>> >> the CT is installed, then how can it not be a MUST requirement?
>> >> Seems to me, that the completion of the handover is predicated
>> >> on CT working.
>> >>
>> >> >And I see no reason for requiring handover signalling to complete
>> >> >before ct (MIP may require it, but that's would be a potential
>> >> >MIP weakness, were it true). Even if this is true, it applies only
>> >> >to reactive ct, and contradicts the purpose of proactive ct.
>> >> >
>> >>
>> >> Right, I didn't say it was a general requirement, I only said
>> >> I see it as a requirement for a particular solution. And I don't
>> >> necessarily see it as a weakness, if it results in faster handover for
>MIP.
>> >>
>> >> >You seem to be implying that there is some dire consequence to be
>> >> >realized if a ct happens but an ho doesn't. At best, the new AR
>> >> >will be holding onto useless context. At worse, the new AR may
>> >> >reserve resources that could be used elsewhere. Either situation
>> >> >seems resolvable with some sort of "life timer" and garbage
>> >> >collection. It does not imply that the two protocols be
>> >> >synchronous.
>> >> >
>> >>
>> >> I'm not implying anything, I'm just trying to figure out where
>> >> you are coming from. I've had my head embedded in this handover
>> >> problem for a while now, particularly with regard to making
>> >> MIP handover fast enough for real time streams, and every time
>> >> I tune into the CT discussion, it seems to be drifting off into
>> >> philosophy and further away from what IMHO is essential engineering
>> >> for getting MIP to work fast. I'm sure I'm probably missing
>> >> alot of context here (so to speak), and I do admit to a MIP bias, but
>I'm
>> >> having some real trouble extracting anything out of this.
>> >>
>> >> >I'm missing the critical state relationship between ct and ho
>> >> >that you are alluding to.
>> >> >
>> >>
>> >> Sure I am. Let's take  a specific example. Suppose we are doing
>> >> network assisted handover in MIP. Suppose that we want to transfer
>> >> the authentication  context and header compression context so that
>> >> we can start up the real time stream on the MN just as soon as
>> >> it shows up on the L2 (otherwise the user ends up hearing a half
>> >> duplex converstation). In order for the handover to successfully
>> >> conclude, the nAR needs:
>> >>
>> >> 1) Signaling from oAR that MN is coming soon,
>> >> 2) The relevent CT for nAR to install,
>> >> 3) Tunneled packets until MN gets around to changing its CoA.
>> >>
>> >> and it needs them in that order.
>> >>
>> >> Suppose they do not arrive in that order. Clearly, 3) being out of
>> >> order first can be ruled out. If 3) arrives before 1, nAR doesn't
>> >> know that MN is coming. If 2) arrives before 1), nAR can wait for 1),
>> >> but that implies a timer. If 3) arrives before 2), the proper
>> >> authentication and header compression state isn't around.
>> >>
>> >> What am I missing?
>> >>
>> >> jak
>> >>
>>
>

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Thu, 12 Jul 2001 07:58:42 -0400

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 11, 2001 6:42 PM
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,
RE: Issue #4)

> If the HO signaling never occurs, the AR must drop the CT at some point,

I am saying that 'some point' is upto the implementor based on memory/system
load/amount of boundedness, etc as to when the state should be re-cycled, or
if some part should be stored in non-voilatile memory.

The implementor could just say that X amount of RAM will be available for
all system operations, and any used memory (CT/HO state) will be freed
periodically.  As far as an RTOS is concerned memory is memory.

All a general timer really determines is how many outstanding CT/HO
operations that an AR can have.  Since ARs come in all sizes and speeds a
general timer is really arbitrary in limiting the number of outstanding
CT/HO operations.

If the HO never occurs the oldest pending CT could just be over-written with
some new CT (A caching policy).

I believe it a  memory management issue that can left to the implementor.

- Kulwinder.

be ,
be ,

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 11 Jul 2001 16:38:06 -0700

Just in case you didn't notice, you are both in agreement :)

PatC