Subject: [Seamoby] Proposal on Sync/NoSync Requirement

From: "James Kempf" <[email-masked]>
Date: Sat, 13 Jul 2002 11:58:54 -0700

So based on the list discussion so far, I'd like to put out the following proposal for a requirement on synchronization or
its lack:

5.5.1 The CT solution SHOULD NOT provide direct support for synchronization of context. However, the CT solution SHOULD allow
particular feature contexts that require synchronization to provide that support.

        Most feature contexts will not require synchronization, however there are a few that may. Header compression,
        for example, may require that the header compressor on the old access router cease and the compressor
        on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor
        on the new router will not be properly synchronized. Since most contexts don't need synchronization support,
       the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do.

Comments?

            jak

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Sun, 14 Jul 2002 14:05:48 +0300

Hi James,

> So based on the list discussion so far, I'd like to put out 
> the following proposal for a requirement on synchronization or
> its lack:
> 
> 5.5.1 The CT solution SHOULD NOT provide direct support for 
> synchronization of context. However, the CT solution SHOULD allow
>   Most feature contexts will not require synchronization, however there are a 
>   few that may. Header compression, for example, may require that the header 
>   compressor on the old access router cease and the compressor on the new 
>   router start in synchrony with hand over of routing to the new router; 
>   otherwise, the compressor on the new router will not be properly synchronized. 
>   Since most contexts don't need synchronization support, the CT solution need 
>   not support it, but it should not provide a hinderance to those feature contexts 
>   that do.

I would rather like it stated that Context Synchronization is out of 
scope for this work.  However, we should note that many contexts
don't require it, but some might.  

John

---

From: [email-masked]
Date: Mon, 15 Jul 2002 01:01:22 +0300

Hi James,

> "Out of scope" is typically WG charter language. I know the 
> SHOULD/SHOULD NOT sounds a bit funny, but I think we need to
> express this in a way that is more requirements language.

Then how about changing:

      ... the CT solution need

to:
      ... the CT solution is not requireed to directly support synchronization, but
      may support simple methods for the synchronization context for feature contexts
      that do.

John

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 15 Jul 2002 10:56:06 -0400

I don't think this requirement really resolves much of the issue
that has been under discussion, namely the level of synchronization
that is to be possible using CT.

CT for updates (as a result of new flows, or flows being discontinued)
is, I think, pretty straightforward. CT for state maintenance where the
state may change while a transfer is in progress is a much harder problem.

It matters not whether we say that CT solves this latter problem, or
provides
the support mechanisms, the demands that this would impose on the protocol
are extreme.

We need a requirement that clearly identifies what is meant by CT
synchronization:

Currently:

5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of updating 
      context information when it changes.

5.5.2 A context update MUST preserve the integrity, and thus the
      meaning, of the context at each receiving AR.

   The context at the AR actually supporting an MN's traffic will
   change with time. For example, the MN may initiate new microflow(s),
   or discontinue existing microflows. Any change of context at the
   supporting AR must be replicated at those ARs that have already
   received context for that MN.

Proposed:

5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of supporting the
      updates to context information when it changes.

5.5.2 Context updates SHOULD complete before the context is needed at 
      the receiving AR.

   The context at the AR actually supporting an MN's traffic will
   change with time. For example, the MN may initiate new microflow(s),
   or discontinue existing microflows. Any change of context at the
   supporting AR must be replicated at those ARs that have already
   received context for that MN.

   However, context changes are often driven by events external to the 
   sending AR, and will thus be asynchronous to any on-going context
   updates. Given that context transfers will take a finite amount of 
   time to complete, it is possible that a change in context cannot be 
   conveyed in time to the destination AR to avoid any impact on a possible
   handover. The objective of the context transfer design must be to make 
   the likelihood of this delay, and its magnitude, as low as possible.

This is not perfect: the desire to avoid a requirement for an extreme degree
of synchronization is only implied by the soft "SHOULD" in 5.5.2. 

Regards,
Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: July 14, 2002 18:52
> To: [email-masked]; [email-masked]
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
> 
> 
> That sounds better.
> 
>             jak
> 
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Sunday, July 14, 2002 3:01 PM
> Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement
> 
> 
> > Hi James,
> >

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 17 Jul 2002 18:36:15 -0500

Don't know if we can use NEED Not (certainly fits for the first SHOULD NOT, since
that one sounds like we are advising against it).
How would you allow particular features get synch service, if there is no inbuild
mechanisms in CT?

I think we can talk about synchronization when there are two copies at
two different places. I think the solutions should seriously avoid this,
as we did in our proposal. Care should be taken so that you don't have to 
update a context at both oldAR and newAR. I think as you said for header compression
context, you should have the context updated only at one location and when
it is only at one location, how can we call it synchronization?

You would on the other hand get problem with dynamic context, if
some context that you sent over, gets lost or corrupted. Once this happen
then, you can see whether the context has changed (in which case you need a refresh)
or not (you only need a retx).

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Saturday, July 13, 2002 1:59 PM
To: [email-masked]
Subject: [Seamoby] Proposal on Sync/NoSync Requirement

Comments?

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 17 Jul 2002 18:42:24 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, July 14, 2002 5:01 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement

Hi James,

Then how about changing:

      ... the CT solution need
      not support it, but it should not provide a hinderance to those
feature contexts
      that do.

Madjid>> I knew I should read some more :) Need not is better. 

to:
      ... the CT solution is not requireed to directly support
synchronization, but
      may support simple methods for the synchronization context for feature
contexts
      that do.

Madjid>> Don't know what purpose "simple" feels, it's vague and creates
caos later. I prefer "methods for providing updated context..." instead of
synchronization, of reasons I mentioned. 

John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 17 Jul 2002 18:42:24 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, July 14, 2002 5:01 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement

Hi James,

Then how about changing:

      ... the CT solution need

to:

John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 17 Jul 2002 19:11:59 -0500

Gary,

thanks for the suggestions, please see my comments below.

Madjid

Proposed: 

 Madjid>> Ok, this takes care of the dynamic context, however,we 
need to be clarify that we are not requiring the oldAR sends updates
to context features it has already transmitted while it is transmitting
context for other features, otherwise CT might never end.
Since, some folks have brought that up, I want to make sure that we
 are not reading that in the requirement. Updates initiated by oldAR
should only be based on outside triggers such as new flow, flow terminations
or messages from central entities...

Madjid>> How do we know when the context is needed at the receiving AR? 
I find this more like a design guidance than a requirement. The following
text
can with some exceptions added to the explanation of 5.5.2.

   The context at the AR actually supporting an MN's traffic will 
   change with time. For example, the MN may initiate new microflow(s), 
   or discontinue existing microflows. 
Madjid>> the above is good.

Any change of context at the 
   supporting AR must be replicated at those ARs that have already 
   received context for that MN.
Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be
(sorry for too many shoulds :)) There are ways to avoid having to do
this through CT. 

Madjid>> The above is good.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 17 Jul 2002 19:11:59 -0500

Gary,

Madjid

Proposed:

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 17 Jul 2002 19:25:41 -0500

Sorry, one correction in my previous email:

Here I meant 5.5.1 only says MUST be capable of supporting (which
I consider as a "should", i.e. individual feature may or may not
use it. In any case I think, it should say:

Any change of context at the 
   supporting AR SHOULD be replicated at those ARs that have already 
   received context for that MN.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 17 Jul 2002 19:25:41 -0500

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 18 Jul 2002 11:11:09 -0400

Madjid:
   
  Comments included:

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: July 17, 2002 20:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf';
> [email-masked]; [email-masked]
>  Madjid>> Ok, this takes care of the dynamic context, however, we 

Actually, the real concern I have is not for dynamic context as it is
for changes in the makeup of the traffic for the MN - i.e. the arrival
and departure of microflows. This would change the configuration (aka 
static) context.

> context for other features, otherwise CT might never end.

I absolutely agree with you.

> or messages from central entities...

There seems to be a concern that CT will not be able to guarantee perfect 
synchronization of the configuration and state of both ARs. My response to
this concern is, of course not, CT was never intended to do such a think.
This is not distributed computing, it is handover optimization.

Perhaps a new requirement would help clarify this, something like:

5.5.x Context transfer SHALL NOT attempt to guarantee perfect
synchronization
of context. The purpose of CT is to improve handover as best as it can.
Given
the complexity and overheads needed to synchronize distributed state
machines,
it is expected that occasionally, the context of the source and destination
AR will not agree. The CT solution must minimize the likelihood of this
happening.

5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale
context
        at the receiving AR. 

To me, this all seems like responding to "what if" scenarios, which if we
got
to far into this mode, could cause the number of requirements to explode. 
However, perhaps this is one distinction we should emphasize.

> I find this more like a design guidance than a requirement. 

Well, a requirement is a design guide. The wg has debated this extensively,
Madjid, with, if I recall, no better resolution then the current wording.
If you have a recommendation for wording of a requirement that would
identify
when CT should be complete, please submit it.

> The following

Hmmm. Could you expand on the "many ways"? I am curious. 

As for MUST versus SHOULD: I think there is an issue here with
interpretation.
My interpretation is that CT MUST ATTEMPT to convey context changes at the
ARs.
That is, CT must provide the mechanisms to transfer context changes to all
ARs
that received the context originally. I agree that it is too extreme to
state
that the changes MUST make it to all ARs. Perhaps some rewording is needed.

> > -----Original Message----- 

Thanks for the response; very useful input.

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 18 Jul 2002 11:11:09 -0400

Madjid:

Gary

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 18 Jul 2002 16:53:35 -0500

Gary,
Thanks for your reply. We are getting there. Please see comments below
 
BR,
 
Madjid
 
<snip> 

Madjid>> Ok, as I recall the context transfer deals with a microflow

as a unit. The discussion of arrival and departure of    microflows is

relevant if you are aggregating multiple microflows, so maybe this

should be added to the section that talks about aggregation, otherwise

I think it is hard to avoid the interpretation I made (dynamic feature
context) 

Madjid>> glad to hear that. 

happening  "Addition: 

by careful consideration of the rate by which context will change over time
. 

 Madjid>> Can't tell if you can put a NON-requirement to a requirement
document :)
but if you think it provides clarity, then fine. I added a little bit more
guidance at the end,
up to you whether you want to use it.  

Madjid>> "Context transfer must not add to the length of the disruption of
the feature, for 

which it is transfering states for, otherwise the use of context transfer

defeats its purpose"

Madjid>> well I didn't say "many". If the change of context is resulted

from an outside event by an outside trigger, the same information

may be sent to the new AR to update the context there instead. 

 Yes, I think you covered it yourself in your new formulation.

Gary

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 18 Jul 2002 16:53:35 -0500

Gary,
 
BR,
 
Madjid
 
<snip> 

defeats its purpose"

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jul 2002 10:08:38 -0400

James:

 You have completely ignored "proactive CT", which for me, and I 
believe others, is the primary value of CT. If you deliver the context
to a receiving AR in the believe that it is a potential candidate for
handover,
and the context at the sending AR changes then an update seems like a
necessary
thing to do. At the very least, the context of newly created flows, or flows

being destroyed, should be conveyed. This could be part of the flow set up
semantics, but it seems wrong to insert CT into flow setup.

 The analogy for proactive CT here is soft handover: seamlessness at the IP
layer is analogous to soft handover at the link layer. 

 Finally, while I still would like to see CT progress, reducing the value of
CT by simplifying the requirements simply to get IESG approval, does not
seem
to me to be an appropriate approach. Proactive CT (now referred to as "CT
before
handover", *sigh*), is 90% of CTs value, to me, and I hope others concur.

Gary

> Sent: July 19, 2002 09:04
> To: Kenward, Gary [WDLN2:AN10:EXCH]; John Loughney; [email-masked]
> I still don't think this is sufficiently crisp. In addition, 
> after reviewing the
> email from the last couple weeks on this, I've seen good
> arguments why the CT protocol itself doesn't need to provide 
> update after
> the context has left the router.
> 
> We seem to be going through a bit of route flapping on this 
> one. Let me slip
> into solution space for just a moment (we'll be out again 
> quickly, never fear).
> The way I see the base CT protocol, it is the following things:
> 
>         1) A container format in which feature context blobs 
> get shipped. The
> container includes an identifier for the feature context, but 
> not much more.
> 
>     2) A procedure for standardizing blob formats. This will 
> require IETF
> standards action, plus IANA specification of type identifier.
> 
> So in order to use the CT protocol, a particular application 
> would have to
> define the following in a standards track specification:
> 
>     1) The detals of the blob layout and the IANA type code,
> 
>      2)  The transport for the CT container + blob,
> 
>      3) The synchronization requirements (if any) with 
> handover events.
> 
> For some feature contexts, there may be no synchronization 
> requirements. For
> others, there will be.
> 
> Popping out of solution space (phew, that was a little 
> tight!) , I see the
> following requirements supporting this situation:
> 
> 5.5.1 The base context transfer protocol SHOULD NOT provide 
> direct support for
> synchronization with outside events, since synchronization is 
> not a requirement
> for all
> or even most feature contexts.
> 
> 5.5.2 The base context transfer protocol MUST allow 
> individual feature context
> specifications to define their own synchronization with 
> external events.
> 
> 5.5.3 The base context transfer protocol SHOULD NOT provide 
> support for updating
> context after it is transfered, since context transfer is an 
> optimization, and
> updates would
> compromise the timeliness of the transfer. Changes in context 
> at the source are
> discarded
> after transfer has been initiated.
> 
>         Most feature contexts will not require 
> synchronization, however there
>         are a few that may. Header compression, for example, 
> may require that
>         the header compressor on the old access router cease 
> and the compressor
>         on the new router start in synchrony with hand over 
> of routing to the
>         new router; otherwise, the compressor on the new 
> router will not be
>        properly synchronized. Since most contexts don't need 
> synchronization
> support,
>         the CT solution need not support it, but it should 
> not provide a
>         hinderance to those feature contexts that do. Any 
> changes in the source
> router
>         that would cause changes in the context are discarded 
> after the context
> has
>         been transferred.
> 
> Comments?
> 
>                 jak
> 
> 
> 
> 
> 
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jul 2002 10:08:38 -0400

James:

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jul 2002 10:31:02 -0400

Madjid:

  I would like to respond to your comments with a general comment, which
hopefully covers much
of the issue. Correct me if this is not the case.

  The fundamental concern here seems to be over the scenario where the
context changes while a 
CT is already in progress. It does not seem to me to be a difficult task to
formulate a requirement
that states that CT will update, but at best, the granularity of the
synchronization will be greater
then the duration of a CT (lots of word smithing required, perhaps, but
doable). As far as I can
discern, the only detrimental effect of sending context updates to receiving
ARs is the protocol overhead.

A receiving AR may always decide that it does not need to use a context
update. It would probably make
this decision when, for example, it was receiving a handover, and had
installed context in preparation for
the arriving flows. In other words, the disruption of attempting to update
the installed context would 
be greater then the disruption of not having the latest context.

Now, dynamic, or state related context updates are a real problem. There is
a big issue as to when to
perform state updates, how often, etc. For example, if the dynamic context
is a packet counter, you
obviously do not want to be updating that context every time it changes. In
our work, we came to
the conclusion that while it was worthwile updated configuration context
when it happened, updating
dynamic context (e.g. state context) was not pratical, and indeed,
transferring of state context only
made sense to attempt just before the receiving AR needed the context.
Again, the assumption here
is that transferring configuration context ahead of time (e.g. ahead of an
actual handover), improves
seamlessness. There seems to be some evidence that it can.

As I see it, this whole discussion is around, as you put it, the
"NON-requirement" of ensuring that the
CT solution is not driven to meet extreme synchronization goals. We could
take this approach to many
of the requirements - e.g. if I say CT has to be fast, does that mean
pico-second transfer times? Clearly
it doesn't, but we do not have a requirement that says "CT should be fast,
but not too fast" (Note: the
actual requirement doesn't use the word fast - this is simply a counter
example). 

Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: July 18, 2002 17:54
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James
Kempf'; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement

Gary,
 
BR,
 
Madjid
 
<snip>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jul 2002 10:31:02 -0400

Madjid:

Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: July 18, 2002 17:54
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James

Gary,
 
BR,
 
Madjid
 
<snip>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jul 2002 10:51:18 -0400

James:

 So you are proposing now that there are also feature specific
CT protocols? If this is true, and we follow your argument,
the we need to revisit all the attributes stated for CT: reliability,
timeliness, etc., etc. to determine what capabilities should be
common, and what capabilities should be feature specific.

 As far as updates go, I think it is a common capability.

Gary

> Sent: July 19, 2002 09:05
> To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
> Madjid,
> > Don't know if we can use NEED Not (certainly fits for the 
> first SHOULD NOT,
> since
> We should (SHOULD? :-) use RFC language.
> 
> > How would you allow particular features get synch service, 
> if there is no
> inbuild
> > mechanisms in CT?
> 
> Because the CT protocol would be just a container format that 
> could be reused by
> many different feature specific protocols. For example, one 
> could use the CT
> container to define an option for use along with handover 
> signaling to transfer
> header compression context. Or, one could use SCTP to 
> transfer security, QoS,
> and AAA context not requiring any synchronization with the 
> handover signaling.
> The latter would require a separate protocol description for 
> how the container
> format is used with the particular transport. For most 
> protocols, the two are
> bundled, but they are conceptually separate and here I can 
> see reasons for
> separating them.
> 
> >
> > update a context at both oldAR and newAR. I think as you 
> said for header
> compression
> Because it is synchronized with an external event, namely 
> handover. With context
> that is not sync sensitive  there is no requirement for 
> synchronization with
> handover because the change in routing doesn't invalidate the 
> context on the old
> router. Conversely, if the non-sync sensitive context is sent 
> a bit early, there
> will similarly not be a problem.
> 
> This is not to state that the non-sync sensitive context 
> isn't dynamic, just
> that the event of handover doesn't invalidate it per se.
> 
> 
> >
> > then, you can see whether the context has changed (in which 
> case you need a
> refresh)
> Dynamic context means that it is changing as the mobile's 
> traffic goes through
> the router, right? So I view that as requiring 
> synchronization with an external
> event, namely handover. Something like accounting information 
> would qualify, as
> well as header compression state. On the other hand, a user's 
> SLA would not,
> because handover wouldn't invalidate it.
> 
>                 jak
> 
> 
> 
>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 19 Jul 2002 10:51:36 -0500

Gary,
 
Agree with most of the things you said, in the interest of getting things
done as quick as possible, if you like to serve the "fundamental concern" as
you put it 
"  The fundamental concern here seems to be over the scenario where the
context changes while a 
CT is already in progress. It does not seem to me to be a difficult task to
formulate a requirement 
that states that CT will update, but at best, the granularity of the
synchronization will be greater 
then the duration of a CT (lots of word smithing required, perhaps, but
doable). As far as I can 
discern, the only detrimental effect of sending context updates to receiving
ARs is the protocol overhead. "

I will say, the following is enough (extracted from your own words with an
insertion: "feature"):

"states that CT will update, but at best, the granularity of the
synchronization will be greater 
then the duration of a feature CT 

I leave the word smithing to you :) but the word "feature" ensures that as I
said you wouldn't 
have to update a feature while you are sending others, also it covers people
who like to support
context retransmissions, while the context is highly dynamic and changes
between retransmissions.
 
Regards,
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 19, 2002 9:31 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; [email-masked];
[email-masked]

Madjid: 

Cheers, 
Gary 
-----Original Message----- 
From: Nakhjiri Madjid-MNAKHJI1 [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: July 18, 2002 17:54 
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James
Kempf'; [email-masked]; [email-masked] 
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement 

Gary, 
  
BR, 
  
Madjid 
  
<snip>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 19 Jul 2002 10:51:36 -0500

Gary,

 
Regards,
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 19, 2002 9:31 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; [email-masked];
[email-masked]

Madjid: 

Cheers, 
Gary 
-----Original Message----- 

Gary, 
  
BR, 
  
Madjid 
  
<snip>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 19 Jul 2002 11:21:49 -0500

James,

Thank you for your respond. Ok, if you say SHOULD NOT in RFC means
NEED NOT, I am fine. I don't remember where it is all was defined.

I think there are two issues I like to point out to:

1-In the CT requirement synchronization, referred to 
content synchronization, i.e. 
matching copies of states at oldAR and newAR each have and not   
and not time synchronization (as you mentioned CT-handover synch).
I don't have any disagreements on CT-HO synch issue, that was reflected
in the multi-phase CT requirements (already in there),
 i.e. critical context and non-critical context
go in different phases.

2- I agree with you on what you said on CT being a container,
blob type and all that stuff, we did all that in TEXT, however,
There are things that no transport protocol can provide.
Consider the following case as we described in TEXT:
You are sending data and context at the same time. Say you are
sending HC context and it get lost. The second time, oldAR must
update HC context and send the updated version, it can't retransmit
what it had sent first time. No transport protocol can do this for you.
This is an update by application layer.  If this can't be supported
in CT, then CT is useless for such protocols. I don't know how a separate
option, that is sent once, would solve this problem.
Unless you somehow build this in CT-transport hook. 

If we reflect this in the requirement, then we are fine.

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, July 19, 2002 8:05 AM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement

Madjid,

> Don't know if we can use NEED Not (certainly fits for the first SHOULD
NOT,
since

> How would you allow particular features get synch service, if there is no
inbuild

Because the CT protocol would be just a container format that could be
reused by
many different feature specific protocols. For example, one could use the CT
container to define an option for use along with handover signaling to
transfer
header compression context. Or, one could use SCTP to transfer security,
QoS,
and AAA context not requiring any synchronization with the handover
signaling.
The latter would require a separate protocol description for how the
container
format is used with the particular transport. For most protocols, the two
are
bundled, but they are conceptually separate and here I can see reasons for
separating them.

> it is only at one location, how can we call it synchronization?

Because it is synchronized with an external event, namely handover. With
context
that is not sync sensitive  there is no requirement for synchronization with
handover because the change in routing doesn't invalidate the context on the
old
router. Conversely, if the non-sync sensitive context is sent a bit early,
there
will similarly not be a problem.

This is not to state that the non-sync sensitive context isn't dynamic, just
that the event of handover doesn't invalidate it per se.

> then, you can see whether the context has changed (in which case you need
a
refresh)
> or not (you only need a retx).

Dynamic context means that it is changing as the mobile's traffic goes
through
the router, right? So I view that as requiring synchronization with an
external
event, namely handover. Something like accounting information would qualify,
as
well as header compression state. On the other hand, a user's SLA would not,
because handover wouldn't invalidate it.

                jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 19 Jul 2002 11:21:49 -0500

James,

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, July 19, 2002 8:05 AM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement

Madjid,

NOT,
since

a
refresh)

                jak