RE: [Seamoby] Proposal on Sync/NoSync Requirement

[Nakhjiri Madjid-MNAKHJI1 <[e-mail]>]

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:[e-mail]]
Sent: Friday, July 19, 2002 8:05 AM
To: Nakhjiri Madjid-MNAKHJI1; [e-mail]
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
> that one sounds like we are advising against it).

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.

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

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.


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

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



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