Subject: [Seamoby] CT Requirements Comments from IESG

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Jul 2002 10:22:10 -0700

I have finally managed to get a couple of technical comments out of the IESG on the CT requirements. More are coming but I think it
might be worthwhile to start discussing these.

1) The requirements say nothing about the maintenance of dynamic context. Something must be said, is this out of scope or what? Gary
tells me that supporting dynamic context was rejected by the working group, but it seems like we cannot punt on at least saying
something about this issue.

2) The requirements say nothing about context which must be modified on the new router in order to be useful. An example is ROHC
context when the mobile obtains a new care of address. How would the CT protocol handle this?

I've asked Gary to lead a discussion on these two issues, please send comments to the list.

            jak

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

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 9 Jul 2002 15:50:33 -0400

James:

  Sorry, but a small clarification: I did not say that dynamic context 
was rejected, I said that I recalled that there was, at one time, a
requirement
that attempted to directly address dynamic context and the need to update it

and that requirement was eventually removed. I think the reason was the
difficulty
in defining "dynamic" versus "static" context, as Charlie outlines in his
response.

  There is, however, a requirement, 5.5, that speaks to context updates in
general:

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.

I am now wondering why this requirement did not answer the IESGs concerns?
Possibly because it does not explicitly mention "dynamic context" or
"dynamic
updates"? 

Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: July 9, 2002 13:22
> To: [email-masked]
> Subject: [Seamoby] CT Requirements Comments from IESG
> 
> 
> I have finally managed to get a couple of technical comments 
> out of the IESG on the CT requirements. More are coming but I think it
> 1) The requirements say nothing about the maintenance of 
> dynamic context. Something must be said, is this out of scope 
> or what? Gary
> tells me that supporting dynamic context was rejected by the 
> working group, but it seems like we cannot punt on at least saying
> 2) The requirements say nothing about context which must be 
> modified on the new router in order to be useful. An example is ROHC

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 9 Jul 2002 16:56:23 -0400

I agree with Vijay and Charlie on the response to this question.
It may still be useful to add this response to the requirements,
explicitly stating that the receiving AR *may* change the received
context for its own use, but the nature of these changes, and how
they are effected are not part of the context transfer solution.

Gary

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: July 9, 2002 16:01
> To: James Kempf
> Cc: [email-masked]
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
> 
> 
> hi Jim,
> 
> James Kempf wrote:
> 
> the context transfer protocol should not worry about this at all.
> it is specific to each feature. for ROHC, the IP addresses have
> to be changed. for IPsec Security Associations, the SPIs maybe
> need to be changed in addition to the IP addresses.
> 
> regards
> Vijay
>

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 10 Jul 2002 10:08:28 -0400

Main Entry: mean·ing 
Pronunciation: 'mE-ni[ng]
Function: noun

4 a : the logical connotation of a word or phrase 

------------

I propose, for section 5.5.2, to replace "meaning" with 
"original syntax and semantics", unless someone has a better
idea.

Gary

> Sent: July 9, 2002 16:56
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]
> ----- Original Message ----- 
> From: "Gary Kenward" <[email-masked]>
> To: "'James Kempf'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 09, 2002 12:50 PM
> Subject: RE: [Seamoby] CT Requirements Comments from IESG
> 
> 
> > James:
> > 
> I suspect that is it. What is "meaning"? 
> 
>             jak 
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 10 Jul 2002 12:58:34 -0400

What does natural language have to do with it?
I am not a linguist, but information representations have 
syntax and semantics (and as a result, they have meaning,
at the very least one would assume, to the originator of 
the information).

'useable' on the other hand, is a wide open term, that could
be interpreted strictly (i.e. the information has to exactly
conformant to the requirements for configuration of the destination
router), or very loosely (i.e. "null" information could be
interpreted as "useable", in the trivial sense). In other words,
there would be no requirement.

The intent of this requirement, which went through much debate
over the meaning of "integrity", is that the CT protocol must 
preserve what was sent by the source. For me, stating that the integrity 
of the information was preserved was enough. The wg decided that
"meaning" had to be preserved.

I cannot think of an example where, if one preserves the syntax and 
the symbol values (i.e. the "bits") of a given piece of information,
the semantics would be lost. But then, I'm not a linguist.

Said another way, the bits of the payload of the CT protocol must 
arrive in the order they were sent, and without any errors. Whether
the receiving AR can understand what the sender sent is not a CT
issue. CT just transfers the context, it does not define it. Thus, it
is not required that the CT protocol ensure "useability" at the destination.
That is a problem for the source. The analogy would be a requirement that
TCP ensure that the application could interpret the payload delivered to it.

It's always perplexed me why this simple, and somewhat obvious requirement,
has been subject to so much controversy.

Gary

> Sent: July 10, 2002 12:09
> Hmm.
> So since there is no natural language conversation going on 
> between these two routers, may I suggest that "meaning" is not a
> sufficiently precise word to use in this context?
> 
> How about something along the lines of "usable to establish 
> services on the new router" or something like that.
> 
>             jak
> 
> Sent: Wednesday, July 10, 2002 7:08 AM
*snip*

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 10 Jul 2002 14:31:18 -0400

A word is often defined as 4 bytes, or 32 bits :-) in many
computational architectures and programming languages.

Neither here nor there, really. I'll wait for further
suggestions/comments on the working of 5.5.2 from the wg.

Gary

> Sent: July 10, 2002 14:12
> "Word" or "phrase", from the definition you cite, typically 
> applies to natural language. I have not heard anyone use that
> terminology for machine readable information, even in 
> programming languages.
> 
>             jak
> 
> Sent: Wednesday, July 10, 2002 9:58 AM

*snip*

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 10 Jul 2002 14:07:19 -0500

hi Jim,

James Kempf wrote:

> 2) The requirements say nothing about context which must be modified on
the new router in order to be useful. An example is ROHC

Madjid>> I agree with both Charlie and Vijay. Also we are getting
into solution space when asking this sort of questions. Our proposal
(TEXT) which is based on BETH idea, deals with Rohc context very nicely.

Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 10 Jul 2002 14:07:19 -0500

hi Jim,

Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 10 Jul 2002 14:18:47 -0500

James, all, 

I think we are walking on a fine line between requirements and solutions.

1-
It was decided long time ago that collection and drainage of context
is not the job of context transfer protocol. whichever protocol entity
injecting its states into the CT protocol is responsible for the freshness
of context. We debated a lifetime field for each context, in case the
context
is dynamic, how you handle these sort of issues is completely in solution
space.
For requirement phase, again I say the freshness of context is the job of
the protocol
unit. Now you can argue that we don't have any reliability mechanisms (such
as
error protection and retransmissions) so after a couple of retries the
context
gets old, but again in the absence of reliability mechanisms only a life
time
mechanisms is the most the CT protocol can do.

2- Usefulness at the new AR is not CT's headache. Rohc is just one thing,
different QoS policies, DSCP<->PHB/ service mapping are another, different
security mechanisms are another. Negotiation is another.
CT is not supposed to deal with adaptation, negotiation, remapping....
CT only transfers what it thinks is the same at both side.
As far as Rohc goes, well change of IP address might change
a lot of things, not just headers (QoS profile is one example, SPI
is another, as Vijay mentioned). I don't think this is CT's problem.
This is the problem of the protocol that uses CT for things that
are not the same at both sides of handover.

Regards,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 12:22 PM
To: [email-masked]
Subject: [Seamoby] CT Requirements Comments from IESG

I have finally managed to get a couple of technical comments out of the IESG
on the CT requirements. More are coming but I think it
might be worthwhile to start discussing these.

1) The requirements say nothing about the maintenance of dynamic context.
Something must be said, is this out of scope or what? Gary
tells me that supporting dynamic context was rejected by the working group,
but it seems like we cannot punt on at least saying
something about this issue.

2) The requirements say nothing about context which must be modified on the
new router in order to be useful. An example is ROHC
context when the mobile obtains a new care of address. How would the CT
protocol handle this?

I've asked Gary to lead a discussion on these two issues, please send
comments to the list.

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 10 Jul 2002 14:18:47 -0500

James, all, 

1-

Regards,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 12:22 PM
To: [email-masked]
Subject: [Seamoby] CT Requirements Comments from IESG

            jak

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 11 Jul 2002 10:34:04 -0400

I understand your intentions James, but as a requirement,
preserving "intended usability" does not make any sense to
me. How does on test that a solution is in conformance to 
this requirement? 

Just to be clear, I don't believe that "preserving meaning"
is a real requirement either. It is also not testable.

I am not just arguing semantics here, if we are going to 
revise these requirements, let's make sure that they are
real requirements.

Perhaps the actual answer is to state exactly what was intended
originally: that the bit order and bit values have to arrive exactly
as they were transmitted.

gary

> Sent: July 10, 2002 18:12
> It's not the same definition
> 
> I suggest:
> 
>       intended useability, of the context at each receiving AR.
> 
>             jak
> 
> 
> 
> Sent: Wednesday, July 10, 2002 11:31 AM

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 11 Jul 2002 15:47:42 -0400

You call it fidelity, I call it data integrity.
I've seen "data integrity" used in publications
(no, I cannot quote references).

What we need is a term that everyone, including the
IESG, can agree upon.

> Sent: July 11, 2002 12:22
> So this requirement is talking about transmission fidelity? I 
> sure would not have guessed that from reading it. I thought it
> intended to talk about usability.
> 
> I would suggest that the wording you have above is really a 
> lot more precise that what is currently in the spec.
> 
> Any other comments? Could we substitute Gary's wording above 
> for "meaning" in the current requirement.
> 
>             jak
> 
>

---

From: [email-masked]
Date: Thu, 11 Jul 2002 16:30:00 -0400

Hi all,
 
jumping in as somebody who has been an observer so far, struggling with the current discussion on
'integrity'.
 
When I look at the current wording, i.e., 
"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.", 
 
and compare this to the plain integrity of the actually transmitted data (i.e., its bits and therefore its semantics)
that has been brought to the table as a replacement now, I'm quite confident that this is not what the requirement 
is talking about. 
 
If we remove the word 'meaning' (which is very vague and free for interpretation for me as well), it is still the word
'integrity' left, which is more than plain integrity of the transmitted data, in particular if we look at the following sentences
in the requirement, which state what kind of integrity is meant (which probably also builds the bridge to the vague 
term 'meaning'), namely that the integrity of a context must be preserved in the sense that a received context at new 
AR at some point t must be the same as the context at old AR at the same time t. This is by far more than plain data 
integrity of the transmitted data. Even if your data has been transmitted correctly, the context might be stale (and therefore 
its integrity is lost) because it had changed at old AR in the meanwhile. The action to be taken is also given in the text, 
namely the change of context has to be replicated to the new AR. As you can (hopefully) see this is by far more than
preserving the 'meaning' of each bit. It mandates that changes in the bit values at one end are reflected at the other
end, i.e., it talks about distributed data integrity in my interpretation of the requirement text.
 
Hence, the actual concern might have been (just guessing) whether or not it is the task of the CT protocol to 
preserve the abovementioned integrity. Maybe, the IESG wants to see this functionality left to the replication logic that resides
within each AR. Or on the contrary, they do not see this important topic covered appropriately. 
 
Regards,

Dirk 

-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 3:48 PM
To: 'James Kempf'; [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

> From: James Kempf [ mailto:[email-masked]]

---

From: [email-masked]
Date: Thu, 11 Jul 2002 16:30:00 -0400

Hi all,

 

 
Regards,

Dirk

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 11 Jul 2002 16:56:29 -0400

Dirk: 
 
  A valid point. There is a certain atomic level of granularity which has to
be
dealt with - that is, there's no protocol in the world that can synchronize
changes in
information that occur at the source while the information is "in-flight" or
being
received at the destination. If changes in context while the context is
being transferred
make a different to the successful performance of CT, then there is no hope.
 
  The problem is most significant for state context transfer. E.g. counters
will continue
to count while CT is moving the context to the destination. Either these
changes have no
significant impact upon the forwarding service provided at the new AR (e.g.
it may not 
matter that a policing meter misses a few packet counts), or a different
mechanism
has to be defined for re-establishing the state context.
 
  The handover is real and unavoidable. Mitigating the disruption to the
service at the new
AR is the challenge. It would be nice if the disruption was nil, but
unlikely.
 
Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: July 11, 2002 16:30
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
[email-masked]

Hi all,
 
jumping in as somebody who has been an observer so far, struggling with the
current discussion on
'integrity'.
 
When I look at the current wording, i.e., 
"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.", 
 
and compare this to the plain integrity of the actually transmitted data
(i.e., its bits and therefore its semantics)
that has been brought to the table as a replacement now, I'm quite confident
that this is not what the requirement 
is talking about. 
 
If we remove the word 'meaning' (which is very vague and free for
interpretation for me as well), it is still the word
'integrity' left, which is more than plain integrity of the transmitted
data, in particular if we look at the following sentences
in the requirement, which state what kind of integrity is meant (which
probably also builds the bridge to the vague 
term 'meaning'), namely that the integrity of a context must be preserved in
the sense that a received context at new 
AR at some point t must be the same as the context at old AR at the same
time t. This is by far more than plain data 
integrity of the transmitted data. Even if your data has been transmitted
correctly, the context might be stale (and therefore 
its integrity is lost) because it had changed at old AR in the meanwhile.
The action to be taken is also given in the text, 
namely the change of context has to be replicated to the new AR. As you can
(hopefully) see this is by far more than
preserving the 'meaning' of each bit. It mandates that changes in the bit
values at one end are reflected at the other
end, i.e., it talks about distributed data integrity in my interpretation of
the requirement text.
 
Hence, the actual concern might have been (just guessing) whether or not it
is the task of the CT protocol to 
preserve the abovementioned integrity. Maybe, the IESG wants to see this
functionality left to the replication logic that resides
within each AR. Or on the contrary, they do not see this important topic
covered appropriately. 
 
Regards,

Dirk 

-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 3:48 PM
To: 'James Kempf'; [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

> From: James Kempf [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: [email-masked]
Date: Thu, 11 Jul 2002 19:08:15 -0400

Hi James,

I do think that this is the issue the IESG was after in the first point.

The reason might simply be a wording of the requirement that is kind of 
confusing. Words like 'meaning' certainly don't help. Further, the
statement that 'a context update MUST preserve the integrity' didn't tell
me in the first place what it is about. 

Let's assume (and we have to agree on this first) that the requirement is about
the following:
If a context has been transferred from old AR to new AR, and the context changes
after this operation, the CT protocol MUST preserve the integrity through updating
the context with its current value, i.e., sending the context again. 

Why this proposal? Assume a context for a state counter (Gary mentioned a policing meter).
In case, that the counter at old AR changes after the context has been transferred, it 
MUST re-send the context in the first place, according to the wording above.

Personally, I think this is enough, although it does not cover cases (how BTW?) in which 
those updates would come too late, and the old (stale) value is used at the new AR. 

So here's my proposal for the wording:

5.5.2 A CT solution MUST minimize inconsistencies in the context's integrity at 
each receiving AR. For that, any changes of context at the supporting AR MUST be 
reflected at those ARs that have already received the context for that MN, i.e.,
a context update MUST be performed through re-sending the context to those ARs.

Regards,

Dirk

>From: ext James Kempf [mailto:[email-masked]]
>Sent: Thursday, July 11, 2002 6:32 PM
>To: Gary Kenward; Trossen Dirk (NRC/Boston); [email-masked]
>Gary/Dirk,
>I think you may be on to something here. I think this might be 
>what the IESG was talking about it the first point, namely the
>lack of discussion of dynamic changes in the context.
>
>Is there some way we could cook this idea down into a 
>paragraph that we could insert for this requirement?
>
>            jak
>
>To: <[email-masked]>; <[email-masked]>; 
><[email-masked]>
>Sent: Thursday, July 11, 2002 1:56 PM

---

From: [email-masked]
Date: Thu, 11 Jul 2002 19:08:15 -0400

Hi James,

Regards,

Dirk

---

From: [email-masked]
Date: Fri, 12 Jul 2002 13:41:06 +0300

Hi James, etc.

Would it be OK to say that something along the lines of

 Information which is dynamic may need to be transfered and any CT solution
 SHOULD be able to manage or cope with this gracefully.

John

> Sent: 12 July, 2002 01:32
> I think you may be on to something here. I think this might 
> be what the IESG was talking about it the first point, namely the

---

From: [email-masked]
Date: Fri, 12 Jul 2002 13:41:06 +0300

Hi James, etc.

John

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 12 Jul 2002 11:48:52 -0400

James:

  Yes, we need to fix it, and I think it is doable. 
Thanks to Dirk for highlighting the real problem here
(I think historically, the integrity requirement came out
of the reliability section, and somehow, got lumped with
synchronization and updates).

  I think the requirements need a bit of rewording, and
the paragraph should fall out from this. I do believe
however, that making the synchronization of context between
old and new AR a MUST requirement would be too extreme, and
result in a brittle solution. CT should certainly do it's best to
provide synchronization, but as was discussed in a recent
exchange, it would be impossible to guarantee synchronization
at any instant.

  Any ideas/comments from the wg?

Gary

> Sent: July 11, 2002 18:32
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
> [email-masked]

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 12 Jul 2002 15:35:26 -0400

I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).

Gary

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Hello folks,
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
> 
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
> 
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
> 
> Regards,
> Charlie P.
> 
> 
> 
> > Gary Kenward wrote:
> > 
> > James:
> >

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 12 Jul 2002 15:35:26 -0400

Gary

---

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

Sorry for coming in too late and I haven't gone
through the rest of emails so I hope I am not repeating
somebody's point.

I agree with Charlie that once the context gets to newAR,
the job of CT is done. otherwise the oldAR needs to know
about the data path, propagation delay and all sorts of things.
We are really worried about dynamic context, we can simply
have the old AR add lifetime info into the latest context 
data and let the newAR decide whether it needs a refresh or not,
and don't make it the responsibility of oldAR to guess the validity
of context at the time of arrival at new AR

We should not forget that CT is optimization for handover,
trying to reduce the latency, we can't keep on sending refreshes
and retransmissions forever.

Madjid

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:15 AM
To: Gary Kenward
Cc: [email-masked]
Subject: Re: [Seamoby] CT Requirements Comments from IESG

Hello folks,

Regards,
Charlie P.

---

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

Madjid

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Friday, July 12, 2002 11:15 AM
To: Gary Kenward
Cc: [email-masked]
Subject: Re: [Seamoby] CT Requirements Comments from IESG

Hello folks,

Regards,
Charlie P.

---

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

Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability requirements and maybe
that was ok, because they depend on the scenario and protocols.
So why talk about sending updates after CT is done?

Madjid
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Gary 

> From: Charles E. Perkins [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > From: James Kempf [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > > From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > > From: ext Gary Kenward [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > > > From: James Kempf [ mailto:[email-masked] <mailto:[email-masked]>  
> > > > < mailto:[email-masked] <mailto:[email-masked]> > ]

---

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

Madjid
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 18 Jul 2002 10:52:02 -0400

Define "done"?
 
Seriously, if CT is performed during or after a handover (reactively)
then, yes, there's not much more that can be done. If the context at 
the destination is out of synch with changes in the source context,
there is an increased risk that the seamlessness of the handover will
be degraded.
 
However, if CT is performed before a handover begins (proactively),
and changes occur at the source AR, then it would seem reasonable to
attempt updates. There is a presumption here that there is something
to be gained in handover performance by performing CT in advance of
an actual handover. It could turn out that CT (and the subsequent installion
of context at the destination AR) is so fast, that leaving the transfer 
of context until a handover occurs (i.e. no proactive, only reactive) is
a sufficient, and simpler solution. We really won't know whether this
is the case until the wg starts looking at CT solutions.

Cheers,
Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Madjid
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Gary 

> > > > > From: James Kempf [ mailto:[email-masked]
<mailto:[email-masked]>  
> > > > < mailto:[email-masked] <mailto:[email-masked]>
> ]

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 18 Jul 2002 10:52:02 -0400

Define "done"?

Cheers,
Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Madjid
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Gary

---

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

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 9:52 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Define "done"? 
 
Madjid>> Exactly my point, if you keep sending updates while you're
sending other context, you are never done.

Madjid>> Yes, assuming you mean L3 handover,
and this is the most critical use of CT: optimization
of handovers. I can't have CT add to feature disruption by getting
into an endless cycle of updates.

Madjid>>sure, but this is not a time-critical CT and CT needs to send
updates because
it started too early on a dynamic context.

  
Cheers,
Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Madjid
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Gary

---

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

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 9:52 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Define "done"? 

 

 
  
Cheers,
Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Madjid
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Gary

---

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

Madjid:

  Two comments:

    1. As I responded to James, using CT in preparation of possible
handovers *is*
       the main opportunity to ensure seamless. Trying to catch up to a
handover,
       once it has begun, is very difficult, and likely to fail in many
cases.

    2. What does "too early mean"? Just as there is no deterministic way to
predict the 
       direction of a mobile, and thus which AR the MN handsover to, there
is no deterministic
       way to predict when this will happen. So, while the network/MN may
know that the
       MN has the potential to handover to, say, 3 or 4 ARs, and can prepare
for it,
       there is no way to pin down the epoch.

  I get the impression that either everyone has forgotten about proactive
CT, or does
not care. Which is too bad, for the boy scouts are right on when they say
"be prepared".

Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: July 18, 2002 17:17
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'Charles E.
Perkins'
Cc: [email-masked]

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 9:52 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Define "done"? 

 

 
  
Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Madjid

---

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

Gary,
 
I see your usage scenario of CT (proactive) as a case for CT, but
not the primary case. This comes handy if you are building "capability
discovery" assisted handovers. 
 
Since we agreed on the text in another email, I won't dwell on this
any further.
 
Regards,
 
Madjid 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 19, 2002 9:15 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Madjid: 

  Two comments: 

Gary 

-----Original Message----- 
From: Nakhjiri Madjid-MNAKHJI1 [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: July 18, 2002 17:17 
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'Charles E.
Perkins' 
Cc: [email-masked] 
Subject: RE: [Seamoby] CT Requirements Comments from IESG 

-----Original Message----- 
From: Gary Kenward [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, July 18, 2002 9:52 AM 
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' 
Cc: [email-masked] 
Subject: RE: [Seamoby] CT Requirements Comments from IESG 

Define "done"? 

  

  

  
Cheers, 
Gary 
-----Original Message----- 
From: Nakhjiri Madjid-MNAKHJI1 [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: July 17, 2002 19:25 
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins' 
Cc: [email-masked] 
Subject: RE: [Seamoby] CT Requirements Comments from IESG 

Madjid 
-----Original Message----- 
From: Gary Kenward [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, July 12, 2002 2:35 PM 
To: 'Charles E. Perkins' 
Cc: [email-masked] 
Subject: RE: [Seamoby] CT Requirements Comments from IESG

---

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

Gary,

 
Regards,
 
Madjid 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 19, 2002 9:15 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Madjid: 

  Two comments: 

Gary 

-----Original Message----- 

Define "done"? 

  

  

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

Madjid