Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10531 for ; Fri, 19 Jul 2002 10:53:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19617; Fri, 19 Jul 2002 10:52:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19328 for ; Fri, 19 Jul 2002 10:51:58 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10502 for ; Fri, 19 Jul 2002 10:50:59 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JEpJU07842; Fri, 19 Jul 2002 10:51:19 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:51:19 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C46@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 10:51:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F33.47107094" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F33.47107094 Content-Type: text/plain; charset="iso-8859-1" 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 > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 19, 2002 09:05 > To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org > 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 > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22F33.47107094 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement

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

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 09:05
> To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> 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
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22F33.47107094-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby