Subject: Re: [seamoby] IRTF mm problem statement

From: James Kempf <[email-masked]>
Date: Tue, 1 May 2001 08:56:53 -0700 (PDT)

Hi Pat,

I agree with PhilN that there is too much emphasis on router failure.

I'd like to see some discussion about targeted update. Current router
protocols indiscriminately flood updates. I think it may be necessary
for MM routing to look at targeting updates just to those routers
that need it. This technology could have broader applicability in
BGP routing as well.

		jak

>Delivered-To: [email-masked]
>Date: Tue, 1 May 2001 07:36:48 -0700
>From: Pat Calhoun <[email-masked]>
>To: Glenn Morrow <[email-masked]>
>Cc: Phil Roberts <[email-masked]>, "[email-masked]'" 
<[email-masked]>
>Subject: Re: [seamoby] IRTF mm problem statement
>Mail-Followup-To: Glenn Morrow <[email-masked]>, Phil Roberts 
<[email-masked]>, "[email-masked]'" <[email-masked]>
>Content-Disposition: inline
>User-Agent: Mutt/1.2.5i
>
>On Tue, May 01, 2001 at 09:39:22AM -0500, Glenn Morrow wrote:
>> Phil,
>> 
>> I'm sorry about not getting comments to you sooner. One point I believe
>> people have misunderstood about using the other routing protocols such as
>> OSPF and BGP is as follows:
>> 
>
>It seems like more of the comments that I have seen so far have been very
>solutions based. Given that this draft is a problem statement to the IRTF,
>which will result in a research project, should we really be getting into 
>protocol details? At this point we need to kick off the research activities,
>and try to stay away from how the problem can be solved.
>
>So, let me ask the following question. Could the interested parties 
>provide comments on how the draft could express the problem better, as 
>opposed to how a particular protocol could, or couldn't, solve the
>problem. 
>
>Thanks,
>
>PatC

---

From: Arthur Ross <[email-masked]>
Date: Tue, 1 May 2001 10:42:26 -0700

Phil:

A very important aspect of MM is missing from this statement: the need for
MM to aware of, in some sense, the radio nature of the connections.

While I believe that the solution(s) should be RTT-agnostic (RTT = radio
transmission technology), it should not be radio-physics-ignorant. I don't
believe for a microsecond that the micromobility problem can be addressed,
or even has much meaning, in the absence of radio physics awareness.

Radio propagation in the ground clutter is unavoidably ugly. Connections
are "soft." They are error-prone and highly variable in their properties
(read: they fade, in several senses). There are well-known
communication-theoretic ways of coping with these problems, but, alas, they
cannot be conveniently isolated to each access point; the best mitigation
techniques will involve interaction among the access points. Several things
come to mind: selection of the best access point(s) (a.k.a. "mobile
assisted handoff" in the cellular/PCS world); power control; transmission
rate, others, diversity transmission/combining. QoS, in particular, is
intimately intertwined with the physics.

Clearly, what I am trying to do here is suggest that this new MM protocol
subsume some (most?) of the RAN functionality that has previously been
ignored in the IP world. I find it very strange that the fast handoff
discussion seems to have assumed that the nature of the physical layer can
be packaged and idealized away in some nice, neat way. Sorry, not so. The
physics is at the heart of the problem, damnit!

Clearly, of course, this is a sort of electro-political hand grenade on the
dinner table, but it needs to be confronted.

I'm not trying to sully the intellectual purity of IP. Rather, I'm trying
to raise awareness of the need for MM to address the low-level behavior of
the radio environment in order that realistic IP-based mobility solutions
can be found.

There are both architectural and protocol implications of radio-aware IP.
Primarily, there will need to be some network functionality that serves as
the diversity combiner/packet distributor. A combo FA-Combiner/Distributor
gizmo comes to mind. Something must be assumed about this architecture to
make progress, IMHO.

And there are two major categories of protocol: those between the RAN and
the MNs, and the interactions among the access points/access routers/mobile
routers. CNP comes to mind in regard to the latter. The whole thing is a
real design challenge, if one agrees that the connectivity, even of the
nominally fixed parts of the network isn't really fixed, but will be
dynamic - devices come & go, change their connectivity, etc. This, I
suppose, is the domain of MANET, with which I am not familiar.

Seems to me that the conceptual interface between MM and the specific RTTs
would be a kind of OOP-like "wrapper" that encapsulates the RTT details,
leaving visible only those aspects that are needed for MM.

To make this proposal concrete, I suggest that §2.2 be augmented as follows:

"2.2 Problem Two"

  "One of the primary principles of the Internet has been end-to-end
   communication. Most (if not all) of the protocols running over IP
   have been designed with end-to-end signaling in mind.  Currently,
   changes due mobility induce unwanted end-to-end signaling. This may
   cause applications running over IP to fail due to delay and latency
   induced by unwanted signaling.  Security, QoS and AAA signaling all
   suffer due to this."

   "Moreover, in a wireless-connected mobile host environment, routing and QoS
   are intimately related to the radio nature of the connection. Effective
   management of communication performance involves cooperation and exchange
   of information among radio access points. Host-based routing will be more
   useful if it supports such communication-engineering aspects of
   wireless mobile IP services. [CNP] may be of use in this interaction."

And add the following to the references:

   [CNP] P. Neumiller, "Applying Contract Net Protocol to Mobile Handover
   State Transfer, Draft-neumiller-seamoby-cnpmobility-00, November 17, 2000.

Sorry to be the skunk at the garden party ...

   -- Regards,
   -- Arthur

---

From: "Rosso, Jean-Michel" <[email-masked]>
Date: Tue, 1 May 2001 11:00:28 -0700

> I'd like to see some discussion about targeted update.Current router
> that need it.

I would second that. In the context of public access (data) networks  there
is a business trend that seems to emerge, which  will allow for "peering
agreements". The business assumption, here, is that no single entity will
own all networks ... fair! and that business arrangements will be made to
rapidly increase wireless coverage. "Peering agreements" will enable roaming
in the short term but will also enable MM across domains in the future. In
other words, targeted updates will provide an efficient mean to deliver
network updates to one's peers (on adjacent networks).

-jmr

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, May 01, 2001 8:57 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [seamoby] IRTF mm problem statement

Hi Pat,

		jak

<[email-masked]>

---

From: Phil Roberts <[email-masked]>
Date: Tue, 1 May 2001 19:08:33 -0400

>  > Re: host routing.  The first item does seem to describe 
> host routing,
>  > doesn't it?
>  > >        Mobility maintaining the same routable IP address 
> of a mobile
>  > >        node or mobile network.
> 
>    No, because it says mobile network as well. That
>    implies the ability to push subnets around, not
>    just host routes.
> 
> 	     Mike
>

True enough.  BTW, have you come up with any suggested language changes to
include this in the draft?

Phil

---

From: "Alan O'Neill" <[email-masked]>
Date: Tue, 1 May 2001 19:57:19 -0400

Phil,

Its a nick pit but we do need to cover the mobile network equally well in
the draft. We are overly dependent on the host routing term (with all its
baggage) so maybe mobile enhanced routing would be better ?

Michael, 

If Phil makes this clear, then I think we can all agree that we are talking
about a very different problem than is presently solved in the Internet,
that of support for rapidly changing prefixes (at mobility rates) where the
prefixes include a large proportion of hosts, and mobile entities are not
renumbered on movement.

Its not the whole problem, just a reasonable slice that if solved brings
community benefits.

Alan.

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: 02 May 2001 00:11
To: Phil Roberts
Cc: 'Phil Neumiller'; [email-masked]
Subject: RE: [seamoby] IRTF mm problem statement

Phil Roberts writes:
 > I see that in the list from the mm problem statement there is something
 > about discovery of network/link/access point characteristics, but nothing
 > like what you were talking about in the email I responded to.
 > 
 > Re: host routing.  The first item does seem to describe host routing,
 > doesn't it?
 > >        Mobility maintaining the same routable IP address of a mobile
 > >        node or mobile network.

	     Mike

---

From: "Alan O'Neill" <[email-masked]>
Date: Tue, 1 May 2001 19:58:49 -0400

Nick pit ?
Nit pit ?
Nit Pick ?

Wow - am I dislexik ?  :-)

-----Original Message-----
From: Alan O'Neill 
Sent: 02 May 2001 00:57
To: 'Michael Thomas'; Phil Roberts
Cc: [email-masked]
Subject: RE: [seamoby] IRTF mm problem statement

Phil,

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 1 May 2001 20:56:03 -0400

> From: Alan O'Neill [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 7:57 PM

I agree.  Changing prefixes, instead of individual routes needs to be apart
of the problem statement.

But, also a way for the sender (or sender's AR) to learn the new attachment
point of the mobile.  Some current solutions assume that mobility is a
problem on the mobile side.  These solutions see mobility as a problem for
the mobile, or ARs near the mobile to solve.  Rather mobility should be
consider a normal state of the entire network.

The both sides of the communication should be able to adjust to the mobility
of the other, by changing where packets are sent.  There is of course
signalling delay involved, but this would get rid of a need for every mobile
device to have a 'home' address (ie. Home Agent type entity).  And the
packet re-direction (wasted bandwidth) involved with having a 'home' entity.

A single point of failure (COA) is not needed, if the new route update is
propagated up the network to where the new route to the remote device,
converges with the old route (most cases).  Followed by a removal of the old
route by the AR at the convergence point.  This can be any number of hops.

For where the routes do not converge until they reach the remote
device/remote AR, it is the remote device's/remote AR's responsibility to
send a route removal message along the old route.  Because, this is where
the route convergence point is located.

With multiple packet flows there will be multiple convergence points.

I would call it a Relative Mobility Protocol, because the routes are moved
relative to the mobility of the source and destination entities (Mobile
Node,Mobile Router,Mobile Network) involved in the communication.

With Relative Mobility the each packet takes the least amount of hops
physically possible to reach its intended destination.

- Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 1 May 2001 23:29:07 -0400

> From: Phil Roberts [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 10:02 PM
> To: 'Phil Neumiller'; [email-masked]
> > No, not to me, at least not from the explanations I have read.
> 
> When this was discussed with the ADs, this was the item that 
> was converged
> on as a nonstarter, because of issues 

> of scalability in terms of forwarding table size 

Forwarding table size is really not that large.  

1. Consider that most people travel from home to work on a continous
incremental path. (no tele-portation).
It becomes a problem localized to approximately a city.  Consider that New
York City has about 14 million people.

A very rough calculation on the upper bound:

14 Megs * 16 bytes (IPv6) = 224 MBytes.

We are not talking about moving the entire planet instaneously.

> and propagation of routing updates

Most routing updates will be from newAR to the oldAR.  How long it takes for
a highly divergent new route change to propagate up the network is not as
important, as long as it is transaction-based at each hop.

Routing updates are done today.

The trade-off is more memory is used for tables, but bandwidth and
computational power is saved that would have been spent on mis-directed
packets.

I did discuss moving subnets with some of the ADs for Bluetooth.  It was
Allison Mankin who suggested using IPv6 and subnet prefixes.  I didn't hear
any ADs object to the idea.  

You were present if I remember correctly in Minniapolis.

- Kulwinder.

> as in the following two
> questions from one of the posts in the thread.  Hence the 
> idea of sending
> this to the IRTF for evaluation.

> > Best regards,

---

From: [email-masked]
Date: Wed, 2 May 2001 09:29:26 +0300

Hi Phil N.,

> His arguments about radio physics can be hidden with an OO
> like abstraction of putting macro-diversity over IP.  That is 
> the big first step to consider.

Do you see this as part of a routing solution, or something
handled above IP?  This is an important distinction.  You have
been discussing this since Spring 2000, but if this is something
that the IETF should persue, let's get down to it.  

I think that we need to break the problem in to bite sized
chunks or we will go nowhere.  IMO, that has been the biggest 
problem in much of what you have been agitating for.  The 
solution lies below IP, on IP, between IP and above IP.  There
is no way that we can just solve all of this with one draft,
one protocol, one whatever.  

I do think that this IRTF routing work is an important piece of
the puzzel, but I think we should focus on the ROUTING part
of the puzzel in this draft.

br,
John

---

From: [email-masked]
Date: Wed, 2 May 2001 09:32:56 +0300

Hi Phil R,

>     I didn't see any of this in the resultant mm problem 
> statement and it didn't come out in the discussions in Minneapolis.  
> Did it not get any consensus in the seamoby design teams?  

As the editor of the draft, I will mention that some of what
Phil N. mentioned was discussed, but not in the broad expanse that
Phil N. presented it in the previous mail.  If there are some concepts
in the MM Problem Statement draft that should be highlighted in
this problem statement, please show it.

Also, this brings up another point.  The current SeaMoby MM Problem
statement will probably not be re-issued as NOONE seems to care ...

best regards,
John

---

From: Vincent Park <[email-masked]>
Date: Wed, 2 May 2001 09:31:57 -0400

Hi Phil,

Some comments below.

> From: Phil Neumiller [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 6:39 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Hi John,
> I am going to respond to your messages in reverse order.
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, May 02, 2001 2:03 AM
> > Hi Hesham,
> > > => I think Phil N point was that you do not need to custom
> > > build protocols for specific L2's. Instead abstracting the
> > > common features of these L2s and considering that in the
> > > MM design. Makes sense to me. What's wrong with that ?
> >
> > It makes sense to me, but where are we going to do this?  Is
> > this part of an API, routing protocol or signaling protocol.
> > I think the burden of proof is upon those who wish to have it.
> 
> There is a new sub-IP work area that has been created in the IETF.
> This is an area where some of the work can be done.  I believe that
> specifically, sub-IP issues that relate to RF are numerous, and in
> many cases COMMON to most RF L2s.  I believe Kulwinder
> (Bluetooth BOF co-chair) has come to the conclusion that an abstract
> triggering mechanism for handoff is desirable.  This would be one
> very good place to start.

I don't disagree with the importance of this work. Potential standardization
of a radio API has been discussed repeatedly within the manet WG. Several
years back a presention of the radio API developed under the DARPA GloMo
project was even presented at one of the WG  meeting. However, I think that
most the worker bees in manet we should work on the routing protocols first
and then worry about possibly enhancing them with link layer metrics. So in
short I don't think that the IRTF routing research group should take on this
work now. Addressing it in another group (as you suggest above) seems
reasonable.

> 
> The IRTF is going to look at micro-mobility, but so far just one
> "solution" has been proposed to study by the IESG.  I think
> we can write drafts for other unknown issues with respect to
> mobility and give them to the IRTF.  I have stated countless time
> with absolutely no rebuttal that mobile IP itself is not well 
> understood
> in the scaling (how local is local mobility), performance 
> (how fast is fast),
> and interaction with ANY proposed micro-mobility protocol.  To
> me this seems like an important area for the IRTF investigate.
>

I think that you are being a little overly critical here. I think that the
problem statement that PhilR put out does not try to limit the scope of
possible solutions. It does point out the common tread of host specific
routes that exists in many of the proposed solutions. Additionaly, I think
that it fairly suggest comparison with MIP and other existing protocols is
needed.  Quote from the draft: "A comparison with OSPF and Mobile IP are
involved in making such an assessment both in terms of relative scalability,
performance, and complexity."
 
> Furthermore, whatever micro-mobility will become, it will need to
> cooperate with both MIP and MANET routing algorithms.  It
> seems of paramount importance to me to understand what this
> interaction is.  If I could draw a Venn diagram in ASCII I would
> show three areas, MIP, micro-mobility-solution-X, MANET,
> each with some overlap.  What is the overlap?  When is using
> one solution more desirable than another?  How does one SWITCH
> from using one to the using the other?

Here I basically agree with you again, but I don't know if it is necessary
to put these things in the draft. If you think so, I would suggest that you
offer some text to PhilR. My belief is that the draft should be breif, and
is simply intended to broadly outline the problem and provide some
motivation. I would hope that once the group starts working on the problem
it will adapt as necessary to come to a good solution. Maybe I have too much
faith in people's ability to come to a good solution regardless of their
starting point.

> Since, Phil R's appears to be reciting the IESG party line, I think it
> would behoove the SeaMoby WG to construct a few IRTF recommendation
> drafts of its own.  I am making these arguments to give the SeaMoby
> workgroup a voice in this process.

I think that PhilR sent this to the seamoby list to get input from the
group. :)

Thanks,

Vince Park

> 
> I think I agree with you John, no-one does SEEM interested?  I don't
> understand why.  This is a crucial piece of the WHOLE IP seamless
> mobility puzzle.
> 
> Thanks and best regards,
> 
> Phil Neumiller
> 
> 
> 
> 
>

---

From: Phil Roberts <[email-masked]>
Date: Wed, 2 May 2001 12:06:02 -0400

>  > OK so the TRUTH of the matter is that the IRTF decided 
> apriori that they
>  > were interested in a host based routes solution.  I can 
> live with that.  I just
>  > like honesty in advertising, that's all.
> 
>    Huh? Now I'm really confused. The problem isn't 
>    host routes, per se -- they're just the pathological
>    case. The scaling problem is when you try to propogate
>    those small prefixes outside of some contained area,
>    usually an AS. My take on the MM stuff is that
>    the interesting part of this is allowing mobile
>    hosts and mobile routers to treat their
>    mobility like normal routing topology changes
>    within an AS.
> 
>    I sure hope that what Pat said is not true
>    because focusing *only* on host routes fundamentally
>    misses the point, and certainly wasn't the
>    sentiment of the MM problem statement.

You've got a real opportunity to make sure a mistake isn't made right now.
Have you got any suggested wording updates in the draft to be sent to the
IRTF?

Phil