Subject: [seamoby] Context Transfer Design Team

From: "Gary Kenward" <[email-masked]>
Date: Fri, 2 Mar 2001 10:09:36 -0500

There seems to be a smattering of consensus that we continue with the
design teams to develop the requirements draft. 

I realize this is very short notice, but are people up to a conference call
this coming Monday (March 5) at 11am?

If I get at least 4 responses, I will go ahead and schedule a call, but
I need feedback by 12 today, EST.

If not, I will set something up for the following Monday.

Cheers,
Gary

==========================================================================

I find that the harder I work, the more luck I seem to have.
- Thomas Jefferson

The contents of this email are Nortel Networks Confidential

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 02 Mar 2001 08:40:44 -0800

> If not, I will set something up for the following Monday.

Hi Gary,

   my deepest apologies for not responding any sooner. I have been trying to
watch closely the email discussion as well as try to aclimatize myself with
the Nokia environment (intern) coming from UCL London.

I have read at least three times the draft requirement and I am a proponent of
the idea that it need a lot more work. I have a different view about certain
things and for that I will be sending you the suggestions that I had in mind
but kept postponing sending them to the group and discussing further.

I think that jumping out to get a couple of new drafts just to capture the
attention of people is something we would need to refrain from if we would
like to produce any results that make sense as a good design not as patchwork
design that tries to capture what the others forgot in the way.

So here are my thoughts. If you feel that they are worth contributed to the
problem statement I would be more than happy to expand and definetely
participate in the draft requirements and problem definition.

Also I am a bit confused with the mailing list. What are we posting on
seamoby_context? seamoby? I see email all over the place here...

So here they are:

Defining Seamless Mobility

The term of seamlessness in the greater context of mobility maps different
semantics according to different
individual mobility contexts classes. These context classes may range between:

security
header compression
Accounting and billing
service provisioning guarantees
session management
tcp-friendliness
roaming
<others..>

In the majority of the above subcontexts seamlessness may distinguish between
subjective/perceived and
objective seamlessness.

The reason for such separation of concerns over the semantics of seamlessness
is apparent as well as two
fold: the degree of seamlessness may be tracked by humans
(subjective/perceived) or automata (objective).

In the light of such semantic separation, seamlessness may be defined as the
sustainment of quantifiable or non
quantifiable metrics over each individual subcontext according

a) to some perceivably acceptable boundaries (upper and lower). A boundary may
be considered acceptable
according to some specific context policy with respect to seamlessness

b) to some objectively qualitative metrics that are bound by specific upper
and lower threshold,  This class of
seamless semantics may at worst be allowed to degrade to perceivably
acceptable boundaries of case (a).

With respect to individual subcontexts seamlessness may be polymorphically
overloaded to denote in the
subcontext of :

1) Security : the sustainment of secure transmission between two entities. In
the case of perceivably acceptable
boundaries, secure transmission may be defined the dispatch of securely
guarded flows according to some
perceived security requirements, such as at least one symmetric/asymmetric
ciphering algorithm within a set of
available one. In the case of objectively acceptable boundaries the
sustainment requirement will need to comply
to specific number of bit-key, availability of PFS, delay bounds on SA
setup/teardown, etc.

2) Header Compression: sustaining compression of header state in IP flows.
Differentiation between levels of
compression (potentially more than 2) may provide a clear separation between
perceived compression (marked
increase on the throuput or decrease of loss rates) and objective compression
(higher density levels in the
compression hierarchy).

3) Accounting and billing: here notion of perceived sustainment can be
identified as provisional/estimate (much
like electricity) metrics over network usage. On the contrary the notion of
objective sustainment of the funtions
may transcend to objective and atomically accurate accounting and billing that
can provide granularity to the last
bit of information.

4) service provisioning guarrantees: sustainment of perceived quality. The
sustainment "metric" upgrade to
objective quality of the network flow depending on the level of granularity
quality is guaranteed upon (bit, byte,
packet, flow, flow-agregate, session, utility).

5) session management: sustaining of is perceived to be the session for an
individual MN. That implies that
certain flows-members of a session may need to be degraded/dropped if their
subjective imprortance is lower
(what people would not consider as their session flow representations (active
ones). Alternatevery the
sustainement metric may transcent in more atomic approaches that consider the
entire session as a critical
sustainment goal (eg. remote cruise control flows of a remotely piloted
vehicle).

6) tcp-friendlyness: the degree of sustainment of tcp-friendlyness metrics in
domain. Loose sustainment of
tcp-friendlyness may be considere as perceived seamlessness, while tight
tcp-friendlyness control on udp flows
(eg CBQ penalties on top of delay) would map over objective tcp-friendly
seamlessness.

Furthermore, the architectural diagram does not provide any rationale about
potential such architectural
diagrams. I can imaging meshing between ARs and ANGs for AD1, however in the
second case AD2, why could
one possibly want to get two ARs on the SAME AP... Juniper these days amongst
others ensure that you need a lot
more AP/BS connected to a single AR before the AR can start feeling that it
doesn't go to sleep. What are the
diagrams try to convey...? a topology?...a realistic one? all potential
topologies of interest? ...a couple that croped
in mind and can be expanded?

The doc defines that more than 1 microflow may be supporting a higher layer
application. Do you intend to go all
the way to the app layer or would be will to stop at 3.5 (say RTP). I do not
see that the definition proposes
optional support or propagation of state all the way up to the app layer.

As a problem statement I would like to see something along the lines of :

Individual microflows may be identified under some seamoby protocol
interaction. Under such seamoby
interactions higher layer above transport, such as RTP or application, may be
provided with the required
SeaMoby semantics (contextual or not) as an added value option,that will
enable apps to support sustainment
BUT MORE IMPORTANT  DECISION CONTROL of seamlessness at the application layer.

The "implicit" of the document declaration that seamless handover would
preserve higher layer context is not at
all clear for a problem statement.

"...degradation of the context for even one of a set of
   co-dependent microflows may have a disproportionate impact on the
   function or performance of the application."

So how is the problem formulated according to that ? I do not see any
formulation from that inference.

I have been thinking about the terminology adopted here. I find a difficulty
digesting the term Feature. Of course
it may mean anything..but I think that the granularity semantics for that
terms are TOO THIN. I would expect to
hear the term feature about a characteristic, not an entire class of
characteristics.

I have been thinking about the terms again and again and believe that we would
need to revisit the terms here
since they are going to be used heavily. My own suggestion in the
term-hierarchy about context transfer is the
following:

Seamoby is called to deal with a set of context classes. Some of them have
been mentioned already above.
Each microflow is being tracked/characterized by the instantiation of context
objects from their respective
context classes. In particular the CT-objects track
Each of these context classes may identify a context signature. The
CT-signature comprizes of the tuple
(capability,state)
Context Capapbility:

furthermore what is the difference between feature state and feature
context....if that is one and the same then
do we need both?

Regs.

Theo

UCL/Mobile Systems group

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 02 Mar 2001 08:48:09 -0800

> If not, I will set something up for the following Monday.

I would further like to propose that the context tranfer design team promotes
the requirements draft to a design draft. This way

1) everybody that would like to propose something new it would be considered
by the totality of the team (much like the fast handoffs v6 /v4 design team)

2) the design would go through a sanity check by at least one peer entity
(sound)
3) faster acceptance convergence
4) faster results
5) long lasting
6) real results instead of changing terminology to the same principle and then
preaching that it is different by 0.0000001 % such that it constitutes a
reason to exist on its own (despite the fact that 99% of the idea is similar
to the rest of the design team participants)

What does the team think ?

Theo

UCL/ Mobile systems group

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 02 Mar 2001 08:41:34 -0800

> If not, I will set something up for the following Monday.

I forgot to say that I would be more than happy to participate in this
conference call please let me know of the details..

Theo