RE: [Seamoby] CT Requirements Comments from IESG

["Gary Kenward" <[e-mail]>]

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

> -----Original Message-----
> From: Charles E. Perkins [mailto:[e-mail]]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [e-mail]
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
> 
> 
> 
> 
> 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:
> > 
> >   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
> > 
> > > -----Original Message-----
> > > From: James Kempf [mailto:[e-mail]]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [e-mail];
> > > [e-mail]
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > 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
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <[e-mail]>
> > > To: <[e-mail]>; <[e-mail]>;
> > > <[e-mail]>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > 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: [e-mail] [mailto:[e-mail]]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [e-mail];
> > > > [e-mail]
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > 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:[e-mail]]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; [e-mail]
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > 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.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:[e-mail]
> > > > <mailto:[e-mail]> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [e-mail]
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > 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.
> > > > > >
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>