Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive

From: Cedric Westphal <[email-masked]>
Date: Tue, 17 Jul 2001 05:23:35 -0700

Henrik,

let's not argue, since we agree. I just replied to your posting for clarification.
Still, there are _eight_ mentions of the word mode in the current requirement
draft, and _all_ the sentences in the proposed words that include the word
mode are in the current draft. Nobody objected to these 8 mentions earlier.
Nobody posted an issue saying: 'modes' are bad. So I hope your understand
my surprise, and my reply. Am I wrong in assuming that words that have been
accepted for several months are satisfying the working group consensus?

Cheers,

Cedric.

Henrik Levkowetz wrote:

> Cedric,
>
>         Your are quite right in that mode may be used more generally, as it was in the
> introduction sentence. This is not what I object to.  It is the much more specific
> usage and examples at the end of the text which I object to, as they actually seem
> to require two separate, different, modes of operation.

>         I'm not in any way particular about the specific wording I proposed, any wording
> that does not enforce two modes would be Ok; I simply submitted text as the decent
> thing to do when proposing a change. If you don't like it, different words could
> be just as fine.
>
>         However, if you don't mean to require that the protocol has two separate,
> different modes, I believe that the text will have to change somewhat. I understand
> the way you wish to use mode, but the current text does not clearly read in that
> manner -- quite the contrary, actually, which is why I commented in the first place.
>
>         Regards,
>                 Henrik
>
> Cedric wrote:
> >
> > Henrik,
> >
> > thanks for the comment. One general reply, before more specific ones in line.
> > You are concerned about something that was present in earlier versions of the
> > requirement draft, and that did not raise any issues back then. The introduction
> > sentence in section 4.5 of draft-ietf-seamoby-ct-reqs-00.txt is:
> > 'it is useful to consider two modes of operation'. Nobody objected to that. People
> > discussed at length what those modes were, but never the term _mode_.
> >
> > So why discuss something that had been accepted? If I hear where you come from,
> > I'd say there is the new multi-phase req that induces changes (so now there is the
> > added 'non exclusive', to underline that both modes can work cooperatively in the
> > same ct if need be). Other cautionary words should be in that multi-phase req.
> >
> > Going through your suggestions, you try to replace 'mode' by 'ability'. I disagree
> > with this. A mode is a way of doing things (how do you attempt ct?), an ability is
> > the capacity of doing things (can you achieve this ct?), these are different notions.
> >
> > A little bit more in-line.
> >
> > Henrik Levkowetz wrote:
> >
> > > Cedric, Gary
> > >
> > >         I find the background explanatory text very good but when you get
> > > into describing the way the protocol will work, I see an assumption
> > > sneaking in which I don't agree to, namely that the protocol will need
> > > to have two _modes_ of operation.
> >
> > For sure, we agree, and I personnaly did not
> > see or intend the implication that you see. I think the very first sentence
> > ('two complementray, non exclusive modes of operation') is clear enough
> > to dispell any doubt about getting locked into one _mode_. There's also
> > a paragraph talking on how proactive evolves into reactive if need be.
> >
> > > Maybe it will, or maybe we will be
> > > able to define / design the triggers and handling at the destination
> > > in such a way that there really will be only one mode. But I think
> > > it's premature to imply two modes, ... maybe you didn't really mean to?
> >
> > To tell you the truth, maybe we don't understand mode the same way. Let me
> > give a picturesque, snow-plowing the driveway kinda example:
> > a car transmission might have a sporty mode and a comfort
> > mode. Marketing guys in Detroit did the requirement: we must support sporty,
> > we must support comfort. Do engineers build two different cars? No, it's just
> > a switch on the dashboard: up, sporty, down, comfort.
> > My point is, a _mode_ is not a _protocol_.
> >
> > >       Anyway, I've suggested revised text inline, below.
> > >
> > >         Best,
> > >                 Henrik
> > >
> > > >
> > > > Hey,
> > > >
> > > > Gary and myself have worked on a new proactive/reactive paragraph
> > > > to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> > > > same terminology.
> > > > Here it is, please comment, thanks,
> > > >
> > > > Cedric.
> > > > -------------------------------------------------------------------------
> > > >
> > > >
> > > > 4.4 The context transfer framework MUST support proactive context transfer.
> > > >
> > > > 4.5 The context transfer framework MUST support reactive context transfer.
> > > >
> > > >    It is useful to consider two complementary, non exclusive
> > > > modes of operation for context transfer:
> > > > proactive and reactive.
> > > >
> > > >    The context transfer process is said to be proactive when the required
> > > > contexts are requested to be in place at the target AR  prior to the arrival of
> > > > MN's packet
> > > > at target AR.
> > > >
> > > >    With proactive context transfer, the idea is to make the context available
> > > > to an AR before it is needed. This means that the context is
> > > > available at the AR before it is required to forward the first
> > > > packet arrival in the MN's traffic. Proactive context transfer is
> > > > coupled to mobile handover only by the requirement that the context
> > > > be in place before the handover of the MN's traffic is complete.
> > > >
> > > >    The context transfer is said to be reactive when it is not proactive.
> > > >
> > > >    The idea is that in a reactive context transfer, no guarantee is made as to
> > > > when the context will be in place at newAR. The context transfer process reacts
> > > > to the handover, but has no control over or knowledge of the handover to ensure
> > > > that it is in places before the arrival of MN's packet at the target AR.
> > > > Reactive context transfer is coupled to mobile handover only by the requirement
> > > > that some handover event is triggering the reaction. Reactive context transfer
> > > > completes as soon as possible, but its completion is independent of the handover
> > > > process.
> > > >
> > > >    Depending upon the network configuration, the MN's velocity and the behavior
> > > > of the mobility solution, a reactive context transfer may or may not complete
> > > > quickly enough for the new forwarding AR to provide a consistent service to
> > > > the first packets of the re-directed traffic.
> > > >
> > > >    In many situations there is no forewarning available of a handover
> > > > and context transfer must be initiated simply because the
> > > > re-direction of the MN's traffic is in progress and the AR needs the
> > > > forwarding context immediately. Because of the physical constraints,
> > > > these situations can  never be completely avoided. Thus, if context
> > > > transfer is to be  performed at all, the fundamental mode of operation
> > > > must be reactive.
> > >
> > > .................................................. Thus, if context
> > > transfer is to be performed at all, its fundamental function must be
> > > reactive context transfer.
> > >
> >
> > I understand what you are trying to do, but saying 'the fundamental function of
> > ct' replies to the question 'what is ct' (the fundamental function of ct is to
> > transfer
> > context), and this addresses the question 'how'.
> >
> > >
> > > >
> > > >    The proactive mode of context transfer is an attempt to further
> > >
> > >    The ability to transfer context proactively is an attempt to further
> > > ...
> >
> > an ability is not an attempt.
> >
> > Henrik, I hope that this helped alleviate your concerns,
> > best regards,
> >
> > Cedric.
> >
> > >
> > >
> > > > reduce any disruption of the service provided to the MN's traffic by
> > > > making the context available to an AR prior to it being needed for
> > > > forwarding. This implies that some network event will occur at the IP
> > > > level to indicate the potential for a handover, prior to the handover
> > > > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > > > trigger a proactive context transfer if there is confidence the context
> > > > transfer can complete before the arrival of MN's packet at the target AR.
> > > > There can be no guarantee that this event will occur or that this confidence
> > > > will be acquired, and thus, a reactive context transfer is
> > > > always required as a contingency.
> > > >
> > > >    This also means that a context transfer that begins in proactive mode
> > > > may, as a result of the MN moving or other changes to the wireless
> > > > environment, be required to complete in reactive mode.  If the target
> > > > AR stays the same, then the same proactive context transfer attempt
> > > > should evolve into a reactive context transfer attempt.
> > >
> > >    This also means that a context transfer that begins as a proactive transfer
> > > may, as a result of the MN moving or other changes to the wireless
> > > environment, be required to complete as a reactive transfer.  If the target
> > > AR stays the same, then the same proactive context transfer attempt
> > > should evolve into a reactive context transfer attempt.
> >
> > >
> > > >
> > > >    As the proactive mode of context transfer is an enhancement, there may be
> > > > situations where the reactive mode is considered a sufficient solution.
> > > > While it is required that the context transfer protocol support proactive
> > > > mode, its use is optional.
> > >
> > >    As proactive context transfer is an enhancement, there may be
> > > situations where reactive transfer is considered a sufficient solution.
> > > While it is required that the context transfer protocol support proactive
> > > context transfer, this ability may not always be implemented or used.
> > >    <<<The last sentence limps a bit, I think. Maybe you'll find
> > >       a better formulation that doesn't go into Modes. /Henrik>>>

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 17 Jul 2001 14:53:04 +0200

Cedric,

	You're right, and I'm to blame for not bringing this up earlier, to the
extent that it would need fixing. Somehow the current wording gives me a more
definite sense of requireing the implementation of two distinct modes, which
I didn't get from the previous wording.

	Maybe I was in too much of a hurry when I read the -00 draft, I don't know.
If everybody else concurs with the current wording, fine, -- I'm still not
convinced that we need to implement separate modes, but if nobody will read
the draft as requireing that, we're fine. It's not the word mode I object to,
it was the possible binding interpretation that jumped out and bit me a little
bit (bite? byte? :-)  ).  Change the wording or not, at will.

	Best regards,
		Henrik

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 17 Jul 2001 08:02:54 -0700

Henrik,

The reason why I proposed the term "mode", was because I don't see the
protocol being any different when used in pro vs re. It's all a question
of timing, and how the nAR handles the CT packet. So, modes (in my mind)
do not imply any protocol changes, but may require some implementation 
tweaking.

Hope this makes sense,

PatC

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 17 Jul 2001 17:35:27 +0200

Right. It seems we are in agreement. :-)	Best regards, Henrik