Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement

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

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

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Jul 2002 06:05:10 -0700

Madjid,

> 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

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.

> 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: "James Kempf" <[email-masked]>
Date: Fri, 19 Jul 2002 06:05:10 -0700

Madjid,

                jak