Subject: RE: [seamoby] proactive and reactive CT definitions

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 20 Jun 2001 19:56:04 -0400

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 6:55 PM
> To: Kulwinder Atwal
> Cc: 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]
> Subject: Re: [seamoby] proactive and reactive CT definitions
> 
> 
> Kulwinder Atwal wrote:
> 
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:[email-masked]]
> > > Sent: Wednesday, June 20, 2001 6:16 PM
> > > To: Kulwinder Atwal
> > > Cc: 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]
> > > Subject: Re: [seamoby] proactive and reactive CT definitions
> > >
> > >
> > >
> > > Hello Kulwinder,
> > >
> > > Kulwinder Atwal wrote:

> Coming back to the point I have raised, I hope you would 
> agree that we have
> to consider reactive CT independent of real-time nature of 
> the traffic.
> Sometimes, all you have is basic connectivity, and you could use it to
> reactively fetch contexts.

I have always agreed with this.  My primary concern is that a seperate
mechanism exist to deal with Real-Time transfers such that lumping all
context into a single packet is an optional feature not a requirement.

I believe that section 5.5 Context Update and Synchronization would cover
the real-time aspect and the reliability section provide a mechanism to
ensure that all of the context was transmitted in case of packet loss.

- Kulwinder. 

> 
> Regards,
> 
> -Rajeev
> 
> 
> 
> > - Kulwinder.
> >
> > >
> > > >
> > > > If I am doing a file download and loose 60mSec lets say to
> > > Reactive CT, I
> > > > will not notice as an End-User.
> > > >
> > >
> > > Rajeev: good example. Not sufficient :-)
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > - Kulwinder.
> > > >
> > > > > -----Original Message-----
> > > > > From: Nakhjiri Madjid-MNAKHJI1
> > > [mailto:[email-masked]]
> > > > > Sent: Wednesday, June 20, 2001 5:30 PM
> > > > > To: 'Rajeev Koodli'; [email-masked]
> > > > > Subject: RE: [seamoby] proactive and reactive CT definitions
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I still don't know whether I should respond to these
> > > issues or not,
> > > > > but it seems that is the going trend.
> > > > >
> > > > > For Proactive, your definition works, and actually it 
> is the same
> > > > > as in the draft.
> > > > >
> > > > > I think this definition of reactive is going backward a bit.
> > > > > We did discuss this issue at length and I think you were in
> > > > > agreement that
> > > > >  reactive CT, does not always mean that CT cannot start until
> > > > > after the MN's
> > > > > packets have arrived.
> > > > >
> > > > > For reactive, CT can happens simultaneous as Handover 
> signaling
> > > > > but it might not finish when handover signaling is complete.
> > > > >
> > > > > What you are suggesting, means that you don't need CT 
> to deliver
> > > > > packets the mobile and are totally moving CT out of 
> the critical
> > > > > path for timing. I guess say for header compression
> > > > > it means that the newAR does not have HC states for a while,
> > > > > assuming it can receive uncompressed packets,
> > > > > But would this work for security and authentication, I
> > > don't think so.
> > > > >
> > > > > I like the current definition for reactive:
> > > > >  "doing CT when handover is imminent" and that means 
> that oldAR or
> > > > > newAR are already engaged in handover signaling, now 
> this could be
> > > > > a L2 trigger that newAR has received or a HI or something
> > > else, but
> > > > > it does not mean completion of handover signaling and
> > > packet routing
> > > > > change.
> > > > >
> > > > > Madjid
> > > > >
> > > > > -----Original Message-----
> > > > > From: Rajeev Koodli [mailto:[email-masked]]
> > > > > Sent: Wednesday, June 20, 2001 1:49 PM
> > > > > To: [email-masked]
> > > > > Subject: [seamoby] proactive and reactive CT definitions
> > > > >
> > > > >
> > > > >
> > > > > Description of issue :Clear, unambiguous definitions 
> are missing.
> > > > >
> > > > > Submitter name: Rajeev Koodli
> > > > >
> > > > > Submitter email address: [email-masked]
> > > > >
> > > > > Date first submitted: June 20, 2001
> > > > >
> > > > > Comment type: 'T'echnical
> > > > >
> > > > > Priority:  ''S'/MUST fix
> > > > >
> > > > > Section:  4.5
> > > > >
> > > > > Rationale/Explanation of issue:
> > > > >
> > > > > The section provides the description of proactive and reactive
> > > > > CT without properly defining what they are. We need the
> > > definitions.
> > > > >
> > > > > Requested Change:
> > > > >
> > > > > Reactive CT: The context transfer process which takes
> > > place subsequent
> > > > > to arrival of a MN's packet at the target AR
> > > > >
> > > > > Proactive (I prfer Charlie's Predictive better) 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.
> > > > >
> > > > >
> > >
>

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 20 Jun 2001 17:12:26 -0700

> context into a single packet is an optional feature not a requirement.

Rajeev: Good. Let's see if we can separate the issues here.

a> reactive CT should include all types of contexts. It is initiated when
the new AR receives an IP packet for MN for which there is no context
present.

b> Lumping all the contexts may not be a good idea. I believe this was the
point Pat made as well.

> ensure that all of the context was transmitted in case of packet loss.

Rajeev: Context update and synchronization is not clear to me, for the
moment at least. We will see what happens with the reliability section.

Regards,

-Rajeev