Subject: [seamoby] Update on Issues from IETF meeting

From: Pat Calhoun <[email-masked]>
Date: Mon, 13 Aug 2001 16:18:40 -0700

All,

Although I need to put together the minutes from the London meeting last week,
I'd like to send out the results from our Issues discussion, and request any
comments before we move on.

There are four pending issues:

Issue 2: This issue has to do with the adoption of the proposed requirement 4.3.

	The consensus in the meeting was to adopt the requirement 
	with some minor wordsmithing.

Issue 4: This issue had to do with new terminology for proactive and reactive
Issue 7: Remove the terminology proactive and reactive

	After some intense discussion on the issue, it was decided to remove
	proactive and reactive, and instead adopt a very simple requirement
	similar to:

	"Context Transfer may occur prior to, during or after a handover."

	Nearly complete consensus on this approach.

Issue 5: This issue was a request to support multi-phasic CTs

	The text proposed at the meeting was:
	"4.9 Context information MAY be transferred in phases, allowing for 
	time critical state to be sent first, and non-time critical state 
	to be sent later.

	The cost of building and sending smaller packets is less, as well 
	as parsing and processing by the receiver. "

	The consensus at the meeting was to adopt the text, but a comment was
	made that how one defines time critical is an issue since anything
	could be send in the initial CT message.

    Each CT profile would need to specify whether it is time-critical.

If someone has any comments on the above, I'd like to hear them now. As you
know, decisions aren't made at meetings, and the list is still the preferred
medium to provide comments. If I hear no objections by 8/21, these changes
will be included in the next revision of the draft will be send to WG last call.

Thanks,

PatC

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 15 Aug 2001 07:19:31 -0700

>         Nearly complete consensus on this approach.

It is very simple indeed, but I am not sure I understand WHERE is the requirement.
If I don't require anything, my context transfer actually MUST happen prior to,
during or after the handover. I can't see when else. By requiring that 'CT MAY occur
at any time', are you planning for
disruptions in the time continuum?

Serioulsy, removing the terminology is not the same as removing the concept.
It looks to me like the baby was thrown away with the bath water. You mention some
'intense discussion', could you elaborate to enlighten those who were not present,
thanks,

Cedric.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 15 Aug 2001 07:14:01 -0700

> Serioulsy, removing the terminology is not the same as removing the concept.

As far as I can tell, proactive vs. reactive was essentially stating when CT
would occur. This, as you state, is not a requirement, and therefore adding
something as simple as what proposed seems to do the same thing with the least
amount of friction.

> 'intense discussion', could you elaborate to enlighten those who were not present,

Here are the rough minutes for this particular discussion:

<minutes>
Issues 4 & 7
-------------

4 - Proactive v.s. Reactive.

7 - Remove pro and re from doc. 

Theo: Why remove? 
Two modes are too limited, may be more than two
modes, putting in reqs will limit to two modes.

Theo: two classes of sets of modes, other distincitions 
necessary. 

Charlie: Don't know yet, revisit issue later. Move
on better understood reqs. Table it.

John Longherty: Talk about protocol modes, examples
rather than modes. Useful to discuss in terms of
examples of how a protocol may work, but not
normative. 

Allison: Design space to consider, potental to 
classify. Don't put in as requirement. 

Majiv: Misunderstanding. Timing req. originally
there, to define timing req need to dig deeper,
need to define in relation to handover, not
supposed to be modes. Solution covers both,
but solutions don't have to cover modes.
Remove if expected to be a mode.

Gary: Mode is the problem, not proactive and reactive.
Mode is the issue, capability is more deescriptive.
Protocol operate on two kinds of capabilities.
Not bit in header, happens in different time relative
to handoff. 

Hemant: Do we need to define temporal characteristics?
Depends on when trigger was sent.

Theo: Shift from mode to timing. Timing in which
you act. CT tends to revolve around time 
restriction. Dismiss timing, then revisit.

Rajeev: Mode -> capabilities won't solve.
MN attaches to new router, is context there or not?
Pro - there, Re - not there. Too much confusion,
put in appendix. 

three options

1) Use word capabilities
2) Remove
3) Move to appendix.

Need to consider revise or keep current text.

Rajeev: Proposed text. If context there when MN
attaches to new router, pro. If there after, re.

Majeev: Timing requirements in req. doc? Will
it delay handover? May want to define pro and
re, if not, triggers may be needed. Confusing
based on starting event and ending event.

Rajeev: Presentation, is a distinction. 

Majeev: Does there need to be a timing
requirement?

Henrik: Cedric's text makes me least happy.
Way it says it is difficult, don't know
discussion says that you implement two
modes. Other than that, OK. 

Gary: Timing requirement is in current doc,
section 5, req for pro and re, current
reqs are wrong, specifies a too tight
timing req, needs to be fixed.
No happy with delegating to appendix, important
part of CT and for seamlessness.

Pat: Advisory.

Gary: No, it must be a requrimenet, proactive,
there when packets arrive at new AR.
Lose and be back in same debate.

????: QoS guy, how would a router react
if first packet had a code point and
the QoS was not there? Would drop.
So there is a timing req. 

Pat: Some
environments where you don't have 
handoff notification, in others,
can.

???: Some networks have it.

Rajeev: Always try to get context transfereed
prior to handover. Not removing possibility 
of moving context. When you invoke CT. 

Henrik: Important to have capability to do flexibly,
as early and late. Shouldn't be an appendix.

Gopal: Can push or pull context, pro or re depends
on timing. 

John Logherty: Local API issue.

Gary: Makes a difference. Multiphasic, only time
is just at time that handover is happening. Later,
state isn't there for packet to be forwarded. 
Other phases, might want to transfer. Static,
won't change. Value in concepts, landscape for
people to work on solutions.

Rajeev: Proactive mode, previous router initiates.
Reactive, new router initiates. Both routers should
be able to initiate. Proactive in either direction.
Is context on new router?

Pat: options

1) leave as is.
2) use word capabilities.
3) remove text from doc -5 
4) remove text to appendix -5 
5) state that CT before, during, or after
handover. - many.

5) wins.
</minutes>

Thanks,

PatC

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 15 Aug 2001 08:21:52 -0700

Pat,

thanks for the minutes. It seems it was indeed pretty intense.
However...

Pat Calhoun wrote:

> would occur. This, as you state, is not a requirement,

...what I state is that saying 'CT may happen prior to, during or after handoff'
is not a requirement, it is just stating the obvious. CT must happen prior to,
during or after handoff, not because you require it, but because basic laws of
physics.

Stating whether or not CT could complete before or after handoff is to me a
requirement.

Cedric.

> and therefore adding

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 15 Aug 2001 08:41:05 -0700

> during or after handoff, not because you require it, but because basic laws of

And most people felt that the pro/re text also didn't reflect any requirements.

> Stating whether or not CT could complete before or after handoff is to me a

So how would you propose changing the text so it reads as an actualy requirement?

PatC

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 15 Aug 2001 09:57:57 -0700

> So how would you propose changing the text so it reads as an actualy requirement?

Together with Gary, we did propose some text. I did not see much objection on the list

about the wording, except some worries about the use of the word 'mode'.
Also, I like John's proposal in Issue 7,
which if I understand it well, is to look at the requirements from the context point
of view, and not from the protocol point of view. Basically, looking at the container
first
to design the crane, and not design a crane and see if the containers fit.

Cheers,

Cedric.

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Wed, 15 Aug 2001 14:48:37 -0400

----- Original Message -----
From: "Cedric Westphal" <[email-masked]>
To: "Pat Calhoun" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 15, 2001 11:21 AM
Subject: Re: [seamoby] Update on Issues from IETF meeting

> is not a requirement, it is just stating the obvious.

I agree that it is obvious, but by stating it as a requirement ensures that,
candidate solutions that only address one of these possibilities are
excluded.

It maybe a "non-requirement", but it ensures that all proposed solutions are
actually flexible enough to consider the basic laws of physics in their
designs.

I would call it an "inclusive" requirement, rather than a "non-requirement".

>  CT must happen prior to,

> Stating whether or not CT could complete before or after handoff is to me
a

I agree, this would be a better requirement.

- Kulwinder.

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Thu, 16 Aug 2001 02:13:23 +0200

Cedric,

	Johns proposal and wording was the first that cut trough
the fog at the meeting, and met with overwhelming agreement because
it stated very simply what seems to have been many people's concern
-- i.e. that a CT protocol _not_ be so limited that it could not handle
any of the conceivable timing scenarios implied.

	As such, it may be obvious, but it is also VERY MUCH a
requirement, and may sort out unsuitable protocol proposals which may
not have the flexibility required.

	Do you actually have anything against it, apart from it being
obvious? I for one am very happy to have this requirement plainly and
simply stated.

	Regards,
		Henrik

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 15 Aug 2001 19:36:43 -0700

Cedric at al.,

I guess the purpose was not to disallow proactive or reactive CT. In fact, having CT to
occur prior to, during and after handover allows for all the possible cases. In the form
of a requirement,

- when the MN arrives at the new AR, it must be possible for the context(s) to be present
at the new AR
- when the MN arrives at the new AR, it must be possible to perform CT when context(s)
is(are) not present in  order to obtain them

In my opinion, this would be enough to proceed on this without getting into a rathole.

Regards,

-Rajeev

---

From: Cedric Westphal <[email-masked]>
Date: Thu, 16 Aug 2001 00:24:42 -0700

Henrik,

> not have the flexibility required.

I disagree with this, but this flexibility is exactly the point I'm bringing up.
The proposed requirement is so much a requirement that I'd like to see ONE ctp that does NOT

meet it. I am sorry, but a ctp that ONLY sends context 2 days after a handoff
does satisfy the requirement, since it 'may occur prior to, during or after', so why
not pick after? Talk about sorting out unsuitable protocols...

Cheers,

Cedric.

---

From: Cedric Westphal <[email-masked]>
Date: Thu, 16 Aug 2001 00:34:37 -0700

> is(are) not present in  order to obtain them

Rajeev,

this I totally agree with. I am concerned the proposed text does not reflect this though.
But I hear where you guys at the meeting come from. Maybe an 'AND' instead of an 'OR':
"CT may occur prior to, during AND after handoff" and let's move on.
Take care,

Cedric.

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Thu, 16 Aug 2001 12:13:29 +0200

Cedric,

	Stating that a protocol SHALL support context transfer which
can occur before, during or after handover blatantly eliminates your
example which does it ONLY 2 days after handoff.

	Henrik

---

From: Cedric Westphal <[email-masked]>
Date: Thu, 16 Aug 2001 03:36:37 -0700

"A CT protocol SHALL support context transfer which can occur
before, during or after handover"
this is not the same as 'CT MAY occur prior to, during, after', and
that makes sense to me.

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 16 Aug 2001 14:31:27 +0100

Ced/All,

   First just to comment that having done some work for the design of a proactive mobility
framework, I can only see that
at the end of the day the terminology will boil down to whatever people's taste sees fit as a term
compliant with the timing intrinsincs of context transfer.

However, I would like to argue in favor of the terms active, proactive and reactive, not because I
have writen a draft about proactive mobility but because I have substantial reasons to believe that
the terms are generic enough to encompass the entire time continuum of _any_  event (not just
context transfer)

As I said in the seamoby meeting the meaning of active (during), reactive (after) and proactive
(before) depends first on the reader and really has got a fractal nature with respect to the
magnitude of
application of the notions since they really do not apply just to a mode of operation as people
_erroneously_  consider. Much like a fractal they apply to a set of modes, or to an ontology of set
of modes, or to a set of ontologies of sets of modes, etc...ad infinitum

Just to exhibit the futility of the discussion on the matter and the fact that at the end of the
day it is more who influences whom (everybody company hats on) rather what the terminology really
reflects I will only cite the meaning of the terms PROACTIVE and REACTIVE from what else, the one
and only source of objectivity which if we do not respect we might as well throw dictionaries away,
deny authority of linguists, and identify a tech terminology anarchy where only the strongest
(hello hats) survives

I am not going to comment on what the oxford dictionary says because I expect people to be able to
identify the etymology of the terms as supplied by the experts of linguistics, in the light of
objectivity:

http://dictionary.oed.com/cgi/entry/00189006?query_type=word&queryword=proactive&edition=2e&first=1&max_to_show=10&sort_type=alpha&search_id=Iz5i-rrbDl0-705

Let us now visit the etymology of the word REACTIVE

http://dictionary.oed.com/cgi/entry/00198331?query_type=word&queryword=proactive&edition=2e&first=1&max_to_show=10&xref=1&sort_type=alpha

I stress the multiplicity of meaning : 1, 2, 3a, 3b, 4

Last but not least the word Active

http://dictionary.oed.com/cgi/entry/00002214

I stress the multiplicity of meaning but stick to notions of  1.a, 3.b, 4.a, 5.

People managed to stick to the terms the label 'mode'.... WHY  did this happen? ..because it serves
them better for the purposes of dissmissing the terms or is it because they have a narrow view of
the world, or is it maybe because they do not really consider the real meaning of the terms? I
wonder...

A CT protocol MUST support at least one of these if it is expected to work in this time dimension

As such to me the above means that:

'a CT protocol MUST support a minimum of at least one time class of event servicing with respect to
mobility, that is active,reactive or proactive event servicing for the purposes of mobility aware
context transfer'

What are the events? I don't care (and why should I) it may be a handoff, it may the connection, it
may be foobar.

The above mean to me that the terms above describe accurately a 'requirement' with respect to the
time period that context transfer comes in effect with respect to an EVENT. The terms are elegant
and comprehensive as long as people know what they mean. Oxford English Dictionary attests to
that...

In that light the above terms do not need replacement really since they do describe accurately what
they are supposed to. As such I personally provide a reason that what Cedric suggested augmenting
the set of requirements with, is valid. It just becomes a matter of taste whether people want to
name it something else, like 'during, before, after' which is more informal.

That is not to say that I oppose to the validity of 'during,before,after'. It is to say that we
have been fighting over synonyms really at a time when we already
identified the right words.

I would personaly like to stick to active,reactive,proactive for the reasons presented above. If
people feel that the 'during,before,after' works better in their head then fair enough, but we just
embark in yet another game of renaming things..

Regs.

Theo

UCL/ Mobile Systems

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 16 Aug 2001 07:07:26 -0700

> "CT may occur prior to, during AND after handoff" and let's move on.

This I can live with.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 16 Aug 2001 07:24:43 -0700

Theo,

My problem wasn't the terms active,proactive,reactive, but the rather long text
accompanying the terms, which caused nothing but confusion and would open up
cans of worms. I find John's proposal to be short and to the point.

If you think that something along the lines of:

"Context Transfer MAY occur before (proactive), during (active) and after (reactive)
a handoff."

would be more acceptable since it keeps the terminology in place, I wouldn't be
against it, and would welcome comments.

PatC

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 16 Aug 2001 16:23:29 +0100

With all due respect I am in favour of the suggestion below. It provides better notion of time and behaviour simultaneously for a CT protocol.

However, I have one question:

is it possible that it can happen proactively (before) AND reactively (after) at the same time?
Aren't these time event a bit mutually exclusive or at best OR-inclusive?

What I am pointing basically is the AND. Shouldn't that be an OR? Boolean logic, reasons clearly for that...

This includes also the possibility of including multi-phasic CT as Gary suggested, simply because OR may include PRO,RE or simply active individually or any
combination of them together, which IMHO is also very important.

What we do not want though is have a need for A  _and_  B.. combinatorially this is restrictive..

Rgs.

Theo

UCL/ Mobile System

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 16 Aug 2001 14:12:00 -0700

> > "CT may occur prior to, during AND after handoff" and let's move on.

Fine with me as well.

Regards,

-Rajeev