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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 2 Jul 2001 13:10:13 -0500

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.
> > > >