Subject: [seamoby] Contract net protocol (phil's draft)

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 4 Jan 2001 17:36:02 -0600

Phil,

I went through your draft. The idea of contract net and bidding is very interesting. There were somethings that were not clear to me, My questions are

1-How many mobility agent would you have per access point.

2-What does the call anchor do? Is it any different than the context? You have one call anchor per call and you have several call anchors per mobility agent and you have transfer the call anchor to the new access point when you handover, so why is this different from saying that you have a context (or what you call contract) and you transfer the context. 
Also what is a call?

3-What if nobody's bid is within your satisfaction (your system quality is the highest as far as QoS, AAA and others)? then what? You excluded the possibility of negotiation.
What you mean by best AP? How do you provide a ranking? Also you cannot apply a constant neighbour ranking that applies to all the users, different users might have different level of demands, hence the ranking would be different.

4-By adding all the what you call "attributes" in the contract, I assume you are suggesting a lumped context transfer of all the states (which is I guess fine)

Thanks and Regards,

Madjid Nakhjiri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 3:43 PM
To: Michael Ruckstuhl
Cc: [email-masked]
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

Hi Michael,

I think you have cut to the chase here with Occam's razor (micromobility is
moving from
medieval to modern thought).  What I really like about your thinking is that you
see
that inter-domain, inter-operator, inter-mobile, inter AP, and inter-XYZ all
will have seamoby
requirements and just maybe a generalized solution may exist.  Its not your
father's
micro-mobility in the "classical" sense anymore.  I would like to twist your
ideas a bit further.

There will be cases where the "same" service provider provides different air
interfaces that
overlap in coverage on both different and the same subnets and in any possible
permutation
on this you can dream up. My argument is that the number of these "now weird"
combinations
is going to go up, not down.  A particular base station may "want" to do things
one way,
whereas a particular mobile may "want" do things another way due too their
perspective.
This is why, we need  (here goes Phil again!!!) something like a contract
bidding algorithm
running between the interested parties (mobility agents? (overloaded term)).

If you think this idea holds any water at all, you may be curious enough to read
the
(albeit a very rough and not ready draft) I-D:

http://www.ietf.org/internet-drafts/draft-neumiller-seamoby-cnpmobility-00.txt

W/respect to RSSI gradients, to me this is just fine tuning, and a much more
serious
problem is that RF coverage in general is spotty.  Its a fading environment full
of
holes, shadows, reflections, etc.  The real problem in my mind is keeping up
multiple
air interfaces until the other one is ready to go and not fading in and out
forcing
ping-poging etc.  I believe handover reliability will go up enourmously if
SeaMoby
institutes a try to do make-before-break before anything else policy.  I realize
this
will not always be possible, but lets build towards this goal.  Also, you can do
some
nifty multi-homing transport things with SCTP should we get far enough along
to discuss that.

BTW, I don't like the term micro-mobility, but we are probably stuck with it.
The
SeaMoby flavor of micromobility IMHO would be more appropriately called Edge
Mobility, since it involves the communication between edge devices like access
points and base stations and mobile nodes (all apologies to the EMA guys!).

Thanks,

Phil

Sent by:  Michael Ruckstuhl <[email-masked]>

To:   "'Kulwinder Atwal'" <[email-masked]>, [email-masked]
cc:    (Phil Neumiller/MW/US/3Com)
Subject:  RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

One of the things I got out of Erik Anderlind's comments (12/20) was the
idea of separating handover on the local service network from selection of
'the (current) best' service network. The MN has its own ideas of best -
billing cost, battery cost, bandwidth cost, etc. However, if micromobility
can satisfy our needs on the current service network, we don't have to jump
through hoops to know all the RSSI gradient information. For the times (and
there will be some) when the current service network cannot maintain our QoS
needs following the handover, notification of this degradation of service
must be propagated to the correct layer on the MN, which would then
re-evaluate local service networks, and choose the 'best'.

I would like to see a segregation of inter- and intra- service network
handovers.

I think that the intra- handovers should be covered by whatever cost
agreements exist between the service provider and the subscriber, presenting
an 'homogenous' network, requiring no real awareness of Full Radio Map
(other networks) by the MN. I think that inter- handovers are more
complicated because the subscriber wants the 'best deal' and may have cost
vs. QoS vs. bandwidth tradeoffs affecting network selection.

Thus, intra-network handover can be made to maintain some BE support while
the MN realizes that an inter-network handover is now required per the
subscriber's configuration. I think the intra-network handover is what
everyone is discussing as micromobility?

mruckstuhl

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Thursday, December 28, 2000 6:02 PM
To: 'Michael Thomas'; [email-masked]
Cc: Dave Oran; [email-masked]
Subject: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

Ok, I couldn't hold it in any longer.  Here it is.  My first crack this
problem.

MicroMobility Outline:

Tri-cell map: upto three of the nearest endpoints in hetro net.
Bi-cell map: upto two of the nearest endpoints in hetro net.
Radio map: a collection of bi-cells or tri-cells forming a hetro net.
Golden min: The minumum RSSI value that will trigger pro-active hand-off.
GUID: unque id for a tri-cell, or bi-cell.

Partial Radio Map Discovery
     Go thru Radio interfaces in preferred order  /* see if we are in a
radio map that we know
          Tx SeaMoby_Tri-cell_GUID       /* transmit the last GUIDS
that we knew current net
                              /* EP will respond with GUID
if correct, or tri-cell map
                              /* and new GUID
     Go until one acceptable QoS is found
Setup Connection                   /* Get up and running on one
good known link first.
Full Radio Map Discovery
     Send a SeaMoby Discovery packet with IDs for the different nets we
may want links for
     Wait for SeaMoby RSSI packets to come back with two RSSI
values,timestamps,QoS per AP
     and the relative position of homogenous APs

we have our relative position of APs and velocity vectors for MN to do
pro-active handoff.
Now we are ready for normal operation

If RSSI is less than Golden value then
Use Seamoby RSSI packets to monitor our relative position to discovered APs
We need at least a bi-cell within the radio map to track our change in
position.
This will tell us which AP is AP (N+1)

Handoff sequence Triggers:

T (Gold_min): The time that RSSI = Golden min
T (Start_ApNew): The trigger to start the microflows on AP(N+1)
T (MnSw_Start): The MN starts switching to the new AP(N+1).
T(MnSw_Stop): The MN finishes switching to AP(N+1).
T(Stop_ApOld): The trigger to stop the microflows on AP

I am ready.  Release the hounds!

- Kulwinder.

---

From: Phil Neumiller <[email-masked]>
Date: Thu, 04 Jan 2001 20:16:26 -0600

Hello Madjid,

Thank you very much for reading the draft and I really appreciate the
comments.  I realize that the draft is "solution" oriented and we
are in the "requirements" phase of SeaMoby, however, I believe one
very important potential requirements is illustrated in this draft.

REQUIREMENT?
Should context transfer be part of the handover decision (micro/macro
mobility)?  I believe it can be.  We can piggy-back our own state as
an AP (or possibly an MN) on our handover request.  This informs our
handover candidate APs of OUR state while requesting the handover.
It seems to be the most efficient way to do things to me (I also
believe is the road the fast handover drafts have went down).

My responses are interspersed below:

Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> Phil,
> 
> I went through your draft. The idea of contract net and bidding is very
> interesting. There were somethings that were not clear to me, My questions
> are
> 
Absolutely ONE chunk of agent software, that sends receives and decides
on the contracts.  This agent works to send contracts on behalf of
clients
that wish to hand-out and acts as an "contract evaluator" on clients
wishing to hand in (sending their bids in).  This agent has THE VIEW of
the EDGE of the local mobility network.

> 2-What does the call anchor do? Is it any different than the context? You have
> one call anchor per call and you have several call anchors per mobility agent
> and you have transfer the call anchor to the new access point when you >handover, so why is this different from saying that you have a context (or what
>you call contract) and you transfer the context.

The call anchor is really is a synonym of the "real-time" call context. 
Only
an anchor (object?) has the "real-time" state of a particular call. 
When the
anchor is tossed, it is a serialization bundle of the anchor, i.e. THE
context
tranfer.

> Also what is a call?

What is a call???  Jeesh, I know you Madjid, you have worked in cellular
a 
LONG time....  OK, a call=connection=(MAIN PATH for a CONNECTION), i.e.
is
something end-to-end that is AAA'd for.  If you don't account for a call
or
have security, encryption, tunnelling, etc, your just handling datagrams
and
that is probably not a call (this gets real sticky though since some RF 
flavors require a ppp or other even to send ICMP messages).  I could use 
connection but call is shorter (SOMETHING CONNECTION ORIENTED).

> 
> 3-What if nobody's bid is within your satisfaction (your system quality is
> the highest as far as QoS, AAA and others)? then what? You excluded the
> possibility of negotiation.

Right.  The very second you add negotiation you open Pandora's box.  If
we
stick to agents that are fair (i.e. not self interested) we get nice
tractable
well behaving code.  When you add negotiation we instantly go non-linear
and
into NP complete problem space.  I think the simple answer here is
POLICY.
The mobile node must have a set of canned policy decisions like:

If I can't get what I want for QoS/AAA state XYZ, I accept NOTHING. 
or 
If I can't get what I want for QoS/AAA state XYZ, I take the next best
thing. 

> What do you mean by best AP? How do you provide a ranking? Also you cannot
> apply a constant neighbour ranking that applies to all the users, different
> users might have different level of demands, hence the ranking would be
> different.

In order for things to work fairly and simply, EVERYONE would HAVE to
agree
on the ranking metric.  This may be an equation that evaluates AAA, QoS, 
compression, work loads, etc., either way the ranking metric is
ESSENTIAL
and must be transitively agreed upon (possibly negotiated (during
initial
configuration, outages, route changes etc)). I think you understand the
draft
Madjid!!!

> 
> 4-By adding all the what you call "attributes" in the contract, I assume you
> are suggesting a lumped context transfer of all the states (which is I guess
> fine)
Exactly!

> Madjid Nakhjiri

Thank you for the excellent comments and questions!

-pdn