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

From: "Gary Kenward" <[email-masked]>
Date: Tue, 3 Jul 2001 09:42:40 -0400

Phil:

  I confess I am confused as to why people keep suggesting that
"proactive" and "reactive" are serial to anything. It has been
stated, many times over, that, ideally, ct overlaps ho. Of course,
one can never prevent the situation where ct has to happen after
ho (although one could argue whether it was worth doing or not).

  I use the term "overlap" specifically, because there are no
absolute events that tie ct and ho together. In some networks,
one can arrange for L2 events to signal that an MN is "visible"
to a new set of base stations, and possibly to a new AR. In 
other networks, and possibly in inter-technology handovers, it
will be necessary to rely upon L3 messaging (from somewhere to
somewhere).

  Tying ct to ho messaging explicitly, would at this point 
limit the value of a proactive/predictive/anticipatory/prophylactic 
approach to context transfer. 

  I do believe there is value in "bundling" application messages
into one transport (i.e. putting some portion of ct with the ho
message), as long as we can do it without making ct MIP dependent.
All in all, this discussion is premature, as we are trying to
get through the requirements, and one of the requirements cannot
be that ct message y = ho message x. This is more then just idealism
on my part: while we may all have our respective ideas about what
the ct protocol looks like, none of us knows what the wg version of
the protocol will turn out to be once we put our collective knowledge
together.

  Finally, just to avoid confusion: you are correct, absolutely, 
serialization is a bad approach.

Gary

> -----Original Message-----
> From: Phillip Neumiller [mailto:[email-masked]]
> Sent: Monday, July 02, 2001 3:37 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric Westphal'
> Cc: Pat Calhoun; [email-masked]
> Subject: CT reliability model was RE: [seamoby] [Issue] Support for
> Multi- Phase CT
> 
> 
> 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: "Gary Kenward" <[email-masked]>
Date: Tue, 3 Jul 2001 11:40:02 -0400

Phil:
 
  My first comment is that I seem to find myself frequently
being accused of trying to bias ct in one direction when in
fact I am trying hard to prevent bias. If I am trying to
pull the conversation away from a certain assumption it's
to take it towards the middle, not the other extreme.

-----Original Message-----
From: Phillip Neumiller [mailto:[email-masked]]
Sent: Tuesday, July 03, 2001 9:58 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; Phillip Neumiller
Cc: [email-masked]
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
lti- Phase CT

I guess I have come full circle on this one Gary.  I don't think its
a sin to build MIP friendly stuff into CT, in fact it is desirable at this
point, especially for FMIPv6++ which looks to be a great improvement.
Until there ARE other mobility protocols in the IETF or somebody 
can point me to some other one they are going to use, it seems
quite illogical to NOT support MIP whole heartedly.
 
Absolutely, I agree. IETF protocols must support other
IETF protocols. But MIP is not a universal mobility solution,
and there are many indications that for certain mobile wireless
networks it will be, at the very least, a *long* time before
MIP is adopted. I don't want to get into the debate over
who is prepared to adopt what again, so I'm going to try
and take the easy way out and say that it's in our charter
(I believe) that CT will work with "other" mobility solutions. 
 
I do agree that MIP has problems.  With some patience and diligence
these things will be worked out over time.  With this being said, 
 
MIP's biggest problem, at the moment, is that it has
very little momentum in the mobile wireless world. As
far as I know, there is only one operational mobile
wireless network that uses it, Nextel (I'm sure that 
statement will open the flood gates of claims and
counter claims).
 
Frankly, MIP doesn't need Seamoby to solve this
problem. The best approach for MIP would be
to solve this within the MIP WG, using MIP
specific solutions.
 
I don't see the value in developing a "general"
CT solution that used MIP messaging. It seems
like a contradiction.
 
and the L2 trigger work going on in FMIP, it also seems logical
to have a L2 trigger that is used by both MIP for handover and
SeaMoby for CT.  The next step is combine the events to optimize
the design IMHO.  I guess I frankly don't see the value of:

A). Proactive CT
B). Reactive CT
C). Polyphasic CT
 
Could you shed some light on why these are perceived as important
in a few sentences?  I don't see the value add.   
 
This would all be so much easier if we could start
looking at solutions. Let's begin with "polyphasic" CT:
I agree with you about the value of this particular "catch
phrase", in that I've always considered ct to be a process, 
not an event. Processes occur over time, and if you want to
divide that time into "phases", fine - to me this is a design
issue.
 
Having said this, people felt that there was a need to require
aggregation, etc. This implied a "one shot" ct process, and
so others decided that it was necessary to counter balance
this with a "polyphasic" / "multiphasic" requirement. I have
no problem either way: I believe that the right way to do
ct will depend upon the network technology/configuration.
 
Now, as for "proactive": the whole idea, originally, was to
make sure that concept of "preparing" for a handover was
understood and agreed upon. Why? Well, it seems obvious
(to me anyways), that you can always react faster if you are
prepared for what's coming. It really is as simple as this.
In truth, this is not a new concept. As you know, the same
approach has been used for years in CDMA.
 
So, I assume you are not against being prepared, but are
perplexed over the brain twisting over nomenclature. So
am I.
 
Gary
 
Best regards,
 
Phil

---

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

>
>I think that two phases are needed, regardless of the MTU size. I
>believe that in order to achieve a seamless handoff, it is necessary
>to transfer time sensitive context blobs as soon as possible (e.g.
>header compression, L2 keying info, L3 SAs). These are necessary
>in order to exchange packets with the mobile, but there may be other
>time sensitive blobs that I haven't thought of as well. Non-time sensitive
>blobs (e.g. accounting session id) are not needed to send/receive packets
>and therefore do not need to be sent right away.
>
>Mind you, if you have a platform (or service) where these blobs can be
>sent in a single transmission really fast, then multi-phasic may not
>be desirable, and shouldn't be mandatory. Even if multi-phasic exists,
>the protocol should allow for all blobs to be sent in the first
>transmission.
>
>

Could the time critical phase be framed as a mobility protocol
extention, so it could be bound to a mobility protocol?

		jak

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 11 Jul 2001 15:12:47 -0400

Rajeev:

I am curious as to what "state" is established by the mobility
protocol that could not be synchronized easily with the end of
ct completion (and visa versa).

I am not saying there you are wrong in suggesting this may be a
problem, it's just that I cannot think of a real example.

Gary

> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 2:16 PM
> To: James Kempf
> Subject: Re: CT reliability model was RE: [seamoby] [Issue] 
> Support for
> Mu lti- Phase CT
> 
> 
> 
> Hello,
> 
> I agree that there is much to gain from doing CT _with_ 
> handover signaling. In
> fact, I have raised this issue of potential state 
> inconsistency (what James calls
> synchronization problem below) a *few times* already in the 
> mailing list. However,
> the value of CT should not be tied to MIP handovers alone. 
> So, the way to make use
> of CT for MIP handovers is to separate the feature contexts 
> from the actual
> signaling messages. This is outlined in 
> draft-koodli-seamoby-ctv6-00.txt.
> 
> Regards,
> 
> -Rajeev
> 
> 
> James Kempf wrote:
> 
> > Hi Pat,
> >
> > >well, the IESG has already stated that their desire was to NOT tie
> > >CTP to MIP (and if memory serves, that was your position until just
> > >recently too). There are other mobility management 
> protocols out there,
> > >and I'd hate to see them have to ignore CTP just because 
> it is part of
> > >the MIP baggage.
> > >
> > >Further, what are the benefits? Sending a single packet, 
> as opposed to two?
> > >Where's the benefit there? I can have two threads work 
> separately in
> > >transmitting the MIP and CT packets. That would reduce the 
> number of locks
> > >required, and introduces modularity. Great benefits IMHO.
> > >
> >
> > I think there may be some benefits to linking CT with the handover
> > messaging.
> >
> > If you send the context and the mobility protocol handover 
> messaging in separate
> > packets, you generate a synchronization problem on the new 
> AR. Furthermore,
> > you increase the risk that a packet could be delayed or 
> lost, disrupting
> > the handover. Suppose that the packets arrive out of order, 
> that is, the CT
> > packet arrives before the handover messaging. The AR must 
> then arrange to buffer
> > and potentially drop the CT packet if no handover messaging 
> arrives within
> > a certain interval. The resulting implementation on the AR 
> becomes more
> > complex, and thus subject to potential failure in more places.
> >
> > Note here that I've said "the mobility protocol", not MIP. 
> I think it
> > should be possible to define the CT messaging so that it is 
> independent
> > of MIP but still can be added to a mobility protocol as an  
> extention,
> > with a binding to that particular mobility protocol. I can 
> easily see
> > how it might work with the network assisted FMIP 
> extensions, and potentially
> > also with (excuse my language) GPRS, as much as I know about it.
> >
> >                 jak
> 
>

---

From: James Kempf <[email-masked]>
Date: Thu, 12 Jul 2001 08:34:40 -0700 (PDT)

John,

An excellent summary of requirements. Depending on the implementation,
some or all of these may or may not be needed.

		jak
		
>Delivered-To: [email-masked]
>From: [email-masked]
>To: [email-masked], [email-masked]
>Cc: [email-masked], [email-masked]
>Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
Phase CT
>Date: Thu, 12 Jul 2001 11:22:09 +0300
>
>Hi Pat,
>
>> time sensitive blobs that I haven't thought of as well. 
>> Non-time sensitive blobs (e.g. accounting session id) are not needed 
>> to send/receive packets and therefore do not need to be sent right away.
>
>I think that discussing of phases is leading us to a dead end.  What
>we need is the following behavior:
>
>1) Ability to send time-critical context
>2) Ability to discard stale context
>3) Ability to synchronize the context transfer with an additional
>   procedure (like a handover)
>4) Ability to use different triggers to start the transfer of some 
>   contexts.
>5) Ability to acknowledge the transfer of some contexts.
>6) Ability to group or send seperately contexts.
>
>My feeling is that when we group the behaviors, we may get the different
>phases - but I think that there may be more than just 2 phases of 
>CT.  Actually, the above behaviors may depend upon the type context
>being transfered.  As we have not identified all the possible types
>of context to be transfered and all of the situations, I don't
>believe that discussing the phases (or modes) of context transfer
>is a good idea currently.
>
>I'm writing up an issue on this right now.  I'm happy to contribute
>text.
>
>Comments?
>John
>

---

From: James Kempf <[email-masked]>
Date: Thu, 12 Jul 2001 08:39:44 -0700 (PDT)

John,

I think Seamoby should do a framework that can be bound to a particular
mobility protocol. The framework might, in fact, be fairly detailed
in terms of on the wire representations and such, it would just not,
a priori, be a separate protocol.

Perhaps there should also be a protocol that wraps the framework for
those mobility protocols that don't want to make CT into an extension.

I believe that the requirements should not specify bundling HO and CT,
and also that they should not forbid it.

		jak
		
>To: [email-masked]
 Phase CT
>Date: Thu, 12 Jul 2001 11:29:31 +0300
>
>Hi James,
>
>I agree with your point, so I think we should allow (not require)
>context transfer to be linked to some messaging.  
>
>However, this opens a big can of worms.  
>
>If CT is linked with other protocols, then is the job to define
>possible parameters & provide a framework on how it is used?
>Then, it would be Mobile IP's job (for example) to use the 
>parameters.  Or do we want to specify a protocol?  Or do we
>specify a protocol seperately from the framework and seperately
>from the parameter types.  The parameter types could be re-used by 
>other protocols (such as MIP).  If MIP is not available, then
>the protocol could be used.  
>
>This I am not sure about, and I'd be happy to see what others 
>think.
>
>John
>

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 12 Jul 2001 13:43:56 -0400

John:

 I agree. Good analysis. I look forward to reading the issue.

Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, July 12, 2001 4:22 AM
> To: [email-masked]; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]; [email-masked]
> Subject: RE: CT reliability model was RE: [seamoby] [Issue] 
> Support for
> Mu lti- Phase CT
> 
> 
> Hi Pat,
>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 12 Jul 2001 17:10:58 -0500

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, July 11, 2001 10:47 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for
Mu lti- Phase CT

Hi Pat,

>recently too). There are other mobility management protocols out there,
>and I'd hate to see them have to ignore CTP just because it is part of
>the MIP baggage. 
>
>Further, what are the benefits? Sending a single packet, as opposed to two?
>Where's the benefit there? I can have two threads work separately in
>transmitting the MIP and CT packets. That would reduce the number of locks

If you send the context and the mobility protocol handover messaging in separate 
packets, you generate a synchronization problem on the new AR. Furthermore,
you increase the risk that a packet could be delayed or lost, disrupting
the handover. Suppose that the packets arrive out of order, that is, the CT 
packet arrives before the handover messaging. The AR must then arrange to buffer 
and potentially drop the CT packet if no handover messaging arrives within
a certain interval. The resulting implementation on the AR becomes more
complex, and thus subject to potential failure in more places.

MN>> James, why is this different than a case where you set up the states
for a call before you actually send the data packets?
In either case the state data might get stale if it is sent too soon and it causes
delay if it is late, this is the general case.
However, the real problem is if you tie the CT trigger to a specific MIP HO signal.
That reduces the number of scenarios where you can do proactive CT.
Don't you agree?

Madjid

Note here that I've said "the mobility protocol", not MIP. I think it
should be possible to define the CT messaging so that it is independent
of MIP but still can be added to a mobility protocol as an  extention,
with a binding to that particular mobility protocol. I can easily see
how it might work with the network assisted FMIP extensions, and potentially
also with (excuse my language) GPRS, as much as I know about it. 

		jak

---

From: [email-masked]
Date: Fri, 13 Jul 2001 08:54:04 +0300

Hi James,

> I think Seamoby should do a framework that can be bound to a 
> particular mobility protocol. The framework might, in fact, be fairly 
> detailed in terms of on the wire representations and such, it would just 
> not, a priori, be a separate protocol.
> 

I think that works for me. 

John

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 13 Jul 2001 10:48:23 -0400

I'm not sure that this is relevant, but there is a difference between
the requirement for multi-phasic ct, and proactive/reactive. The latter
are modes of operation - really just attempts at trying to characterize
when ct happens relative to ho (without being technology specific).

Multiphasic ct says you perform the ct over a number of transfers, and
use some method of prioritization to determine the order of context 
transfer.

There seems to be controversy around both, but they are separate issues.

Appologies if this was already obvious to everyone.

Gary

-----Original Message-----
From: Henrik Levkowetz [mailto:[email-masked]]
Sent: Thursday, July 12, 2001 3:39 PM
To: seamoby
Cc: john.loughney
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for
Mu lti- Phase CT

Ooh, well put, John.

	Best, Henrik