Subject: CT reliability model was RE: [seamoby] [Issue] Support for Multi- Phase CT

From: Phillip Neumiller <[email-masked]>
Date: Mon, 2 Jul 2001 15:37:25 -0400

In the pre- and post- conditions you are serializing something that
clearly does not have to be.  From very basic reliability theory,
it is clear to that combining the CT with another essential message,
the HR_request is the proper optimization.

proof:

For components in series, the joint reliability is given by:

Rs = R1 * R2 * ... * Rk.

For components in parallel:

Let Uk = 1 - Rk, then

Rp = 1 - (U1 * U2);

Suppose that CT is CTr reliable and Handover is HOr reliable.

Then pre- and post- methods are:

Rpre_post = CTr * HOr reliable

and in handover CT is 

Rin = 1 - (Uct * Uho) reliable

Assuming Uct > .5 and Uho >> .5 to have a useable system, thus

Rin >> Rpre_post

So a "IN" handover CT is far more reliable than either pro- or reactive-.

QED

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Monday, July 02, 2001 2:10 PM
> To: 'Cedric Westphal'; Nakhjiri Madjid-MNAKHJI1
> Cc: Pat Calhoun; [email-masked]
> Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT
> 
> 
> Cedric,
> 
> If proactive MUST be multiphasic, then reactive MUST be
> multiphasic too, don't you think?
> 
> You are in more trouble (higher probability of loosing
> packets) when you are doing reactive than when you are
> doing proactive, so it is even more important that
> you send "urgent context" earlier than other context, when 
> you are doing reactive.
> 
> Madjid
> 
> -----Original Message-----
> From: Cedric Westphal [mailto:[email-masked]]
> Sent: Friday, June 29, 2001 6:40 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Pat Calhoun; [email-masked]
> Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT
> 
> 
> 
> 
> Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> > Hi cedric,
> >
> > -----Original Message-----
> > From: Cedric Westphal [mailto:[email-masked]]
> > Sent: Tuesday, June 26, 2001 9:35 AM
> > To: Pat Calhoun
> > Cc: Gary Kenward; [email-masked]
> > Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT
> >
> > I agree with this (the support for multi-phase ct proposal)
> > and would actually go one step further:
> >
> > requirement: a proactive transfer MUST be multiphasic (so 
> that accounting
> > transfer can be transfered after the handoff and config 
> transfer before
> the
> > handoff)
> > a reactive transfer SHOULD be monophasic.
> >
> > MN>> I don't agree, I think it is actually more important to have
> > a multiphasic CT for reactive than it is for proactive.
> > If you had to wait for packet delivery until the end of CT
> > (which I am not proposing) then
> > You would loose more packets in reactive. Hence you should break
> > CT into pieces. After sending the more urgent context, you could
> > resume packet delivery and at the same time, take your time with
> > less urgent context.
> 
> [cedric] I agree with the fact that reactive CT could be pluriphasic,
> that's why it is a SHOULD, not a MUST.
> Or are you saying that _all_ CT should be in several phases? Are you
> proposing that 'CT, even reactive, MUST be in several phase'? I hope
> not.
> 
> > and the distinction between proactive and reactive becomes 
> one of a number
> > of phases.
> >
> > MN>> yet another proactive/ reactive definition, please give us a
> > break :)
> 
> [cedric] not a definition, a distinction ;).
> Take care,
> 
> Cedric.
> 
> >
> >
> > Madjid
> >
> > Cedric.
> >
> > Pat Calhoun wrote:
> >
> > > On Fri, Jun 22, 2001 at 03:23:43PM -0400, Gary Kenward wrote:
> > > >   I with you up until that last two paragraphs of the 
> proposed new
> texts.
> > > > The second to last paragraph is editorial, and presumes 
> much about the
> > > > context,
> > > > the ctp design and the implementation.
> > >
> > > ok, I am certainly open to suggestions.
> > >
> > > >   As for the last paragraph, I do not see the need to 
> add priority to
> CTP.
> > > > It is already required that the receiving AR process 
> the context in
> the
> > > > order received, and this yields the same result 
> (priority can always
> be
> > > > translated to a measurable performance criteria, such 
> as "processed
> sooner"
> > > > or "given more resources"). I do not see the utility of 
> a "priority"
> bit.
> > > > Perhaps you could
> > > > elaborate?
> > >
> > > This isn't a question of a bit. It has to do with sending 
> critical CT
> > > information that is REQUIRED in order to deliver a single 
> packet to the
> > > mobile. This could include HC state, session keys, etc. 
> This state info
> > > is sent first when a handoff is occuring.
> > >
> > > Later (say, 1+ seconds later) additional state is sent. 
> Although this
> > > info is important, it may only be necessary when doing 
> things such as
> > > generating accounting messages, which are infrequent, and 
> not required
> > > during the handoff process.
> > >
> > > >   Otherwise I have no problem with the additional requirement
> (although I
> > > > wonder what an operator would say about "accounting" being "low
> priority"
> > > > ;^}).
> > >
> > > :)
> > >
> > > PatC
> > >
> > > >
> > > > Gary
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Pat Calhoun [mailto:[email-masked]]
> > > > > Sent: Thursday, June 21, 2001 6:37 PM
> > > > > To: [email-masked]
> > > > > Subject: [seamoby] [Issue] Support for Multi-Phase CT
> > > > >
> > > > >
> > > > > Issue 5: Support for multi-phase CT
> > > > >
> > > > >      Submitter name: Pat Calhoun
> > > > >      Submitter email address: [email-masked]
> > > > >      Date first submitted: June 21,2001
> > > > >      Reference:
> > > > >      Comment type: T
> > > > >      Priority: 1
> > > > >      Section: 4.9
> > > > >
> > > > >      Rationale/Explanation of issue:
> > > > >      The current requirement in section 4.9 states 
> that a CT can
> only
> > > > >      occur once all of the state has been gathered. 
> The CT protocol
> > > > >      must allow for state to be transferred in 
> phases, where the
> high
> > > > >      priority state (e.g. Header Compression, session 
> keys) is sent
> > > > >      first, and low priority items are sent at a 
> later time (e.g.
> > > > >      accounting information).
> > > > >
> > > > >      This would reduce the size of the high priority 
> CT packets,
> > > > >      lower the computational cost of processing the packet,
> > > > > and decrease
> > > > >      the handoff latency.
> > > > >
> > > > >      Requested change:
> > > > >      Change 4.9 to state something like:
> > > > >
> > > > >      "4.9 Context information MAY be transferred in phases,
> > > > > allowing for
> > > > >      higher priority state to be sent first, and 
> lower priority
> > > > >      state to be sent at a later time.
> > > > >
> > > > >      The total cost of processing a smaller packet with high
> priority
> > > > >      state is smaller, and would decrease any latency
> > > > > introduced by CT. Each
> > > > >      CT profile would need to specify whether it is 
> to be considered
> > > > >      as a high or low priority state."
> > > > >
> > > > >      Proposal:
> > > > >      Adopt the text above in the -01 version of the
> > > > > requirements spec.
> > > > >
>

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 03 Jul 2001 00:21:09 -0700

Phil,

you are right. Even though I'd say discussing the phases of a proactive or a
reactive CT is premature since there is no clear understanding of what is
proactive or reactive.
About your serialization point, most of the pre or post condition have to be
considered with respect to having the newAR being default router, or the MN
receiving packets from the newAR (cf. those pro/reactive threads), not the
pre or post handover  signaling. So I am not sure we are talking about
the same thing.

Cedric.