Subject: Re: [nemo] comments on "Tree Discovery" draft

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Aug 2004 15:16:36 +0200

Pascal Thubert (pthubert) wrote:
> A typical example is cars in a city. You have a number of antennas 
> distributed in buildings, but down there, there are a lot of shadow 
> area.  So cars will hop over other cars.

Yes, but related to quickness, to you think an individual car will have
to change its CoA very often per second, from connecting to the car in
front to connecting to the now-visible AP on a building?

It is true that our human perception of many little cars moving in a
crowded city streets makes think of Brownian movement, and one-to-one
packet-switched communication (instead of broadcast) looks like an
interesting challenge.  But throw over this some blanket wireless
coverage areas (or "canopies", adv.) and the picture is different, to me.

> But it is clear that my connectivity is impacted by its movements, 
> and I wan to know what I get from him vs other potential attachment 
> routers. With TD I can swap at anytime. With OSPF, changing the 
> neighbors impact the whole AS dramatically? And what is my AS, 
> anyway?

"dramattically" depends to the size of that AS, so let's make your AS be
a small set of routers.  Let's say that a NEMO OSPF AS can have maximum
10 MR's, thus impact is manageable with current hardware, a speculation.

Couple to this the necessity to have a single OSPF area for each MR and
its HA pair.

> There's a lot we have to figure out about metrics. E.g; Even if you 
> have little relative movement with the car in front of you that you 
> hop over, it's hard to define if itself will see the antenna for a 
> long time or in a short window. The thing is building this logical 
> tree simplifies the problem set and makes it manageable.

Right, trying to predict where the device moves is very difficult.

> Did you look at the draft?

Yes, quickly.

> You may compare the flows with what it take to establish neighbouring
>  and distribute the databases.

I don't see flows in the draft and I can't find "flow" either...

>>> If you are interested in the applicability of OSPF in a MANET 
>>> environment, please have a look at the activities that now take 
>>> place in the OSPF and MANET WGs on that respect. You'll find that
>>>  it's a great idea and that there's a lot of work to get there. 
>>> One good thing for MANET is that OSPFv3 uses linklocal whereas v2
>>>  requires that peers have an address on the same network.
>>> 
>>> Then again, it would be slower than TD for many applications. TD 
>>> is not a routing protocol, it's much simpler and quicker. It does
>>> just what nested nemo needs to get out.

If it doesn't grow up into a routing protocol then it'll never avoid
loops and offer short paths.  BTW, do you think loops are impossible
with TD?

> Sure. Is issue 24 a problem that we want to handle for NEMO?  Or do 
> we leave it all to MANET/OSPF?

As I said in my reply on Issue 24 itself, I do not see that to be a
problem.  The looping described in issue 24 assumes simultaneous L2
connectivity of one interface to two wireless access systems, something
impossible.  That problem has not been refined since.  That is not a
problem, and so it can not be solved in NEMO and in no other WG present
or future.

The RA confliction problem can never appear in practice once the various
wireless access systems covering a common area are (1) different in
nature, frequency, encoding or (2) protected by different sec keys.  If
two such systems fail both conditions, L2 connectivity is unclear, a
much bigger problem that the little NEMO Mobile IPv6 support.

The "cross-over" tunnels problem still holds as a NEMO problem.

The "disconnected operation" problem still holds as a NEMO problem.

Unoptimal long multi-angular paths looks like a NEMO problem.

> The assumption in TD is that building that tree and only that tree is
>  enough for nested nemo operation with the infrastructure, and can be
>  done quicker than if you use an abstraction that handles more 
> meshing. The implementation delivers an actual proof of that, but if 
> you just look at the flow

What flow?  Do you mean the numbered list 1-9 of rules and definitions
that MUST be followed by all Mobile Routers in section 5 Tree Discovery?

Alex

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 26 Aug 2004 13:53:52 +0200

Hi Alex: all good questions :) see inline

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: jeudi 26 août 2004 11:00
> To: Pascal Thubert (pthubert)
> Cc: Fan Zhao; [email-masked]
> Subject: Re: [nemo] comments on "Tree Discovery" draft
> 
> >> existing graph.  And, speaking of which, I'm sure OSPF builds
> >> spanning trees, which may even be minimal.
> >>
> >> Which leads me to offer my humble point of view replying to your
> >> request: investigate instead the use of OSPF within an aggregation
> >>  of moving networks.  Which raises the question: why not.
> >>
> > Well the key is how quickly things come up, and how the solution
> > being deployed survives quick movements. TD is optimized to obtain
> > one tree, and it does it in one pass.
> 
> Look, I'm eager to find a more expressive definition of this "quick"
> word.  What is a "quick movement" by the way.  In Mobile IP terms, it is
> something related to how often the CoA is changed per time unit (e.g. 3
> CoA changes per second is quick, 1 CoA per second is normal and 10 CoA
> per second is very quick).  Note how different is this from the physics
> terms where speed is physical distance over time; this physical
> "quickness" is in no way related to the Mobile IP quickness because
> there may be very large rectilinear areas where you go 220km/h and still
> don't change the CoA (Mobile IP "quickness" is really below normal).
> 
> So, having this in mind, do you have an idea of a practical setup where
> the NEMO MR's nest and form aggregations and at the same time they are
> very "quick" in terms of Mobile IP to each other.

I do agree with that definition of CoA change rate. A typical example is cars in a city. You have a number of antennas distributed in buildings, but down there, there are a lot of shadow area.  So cars will hop over other cars. But it is clear that my connectivity is impacted by its movements, and I wan to know what I get from him vs other potential attachment routers. With TD I can swap at anytime. With OSPF, changing the neighbors impact the whole AS dramatically? And what is my AS, anyway?

There's a lot we have to figure out about metrics. E.g; Even if you have little relative movement with the car in front of you that you hop over, it's hard to define if itself will see the antenna for a long time or in a short window. The thing is building this logical tree simplifies the problem set and makes it manageable. Did you look at the draft? You may compare the flows with what it take to establish neighbouring and distribute the databases.

> > environment, please have a look at the activities that now take place
> >  in the OSPF and MANET WGs on that respect. You'll find that it's a
> > great idea and that there's a lot of work to get there. One good
> > thing for MANET is that OSPFv3 uses linklocal whereas v2 requires
> > that peers have an address on the same network.
> >
> > Then again, it would be slower than TD for many applications. TD is
> > not a routing protocol, it's much simpler and quicker. It does just
> > what nested nemo needs to get out.
> 
> TD is quicker than what?  TD is "quicker" like accomodating quicker MR
> movements?  How many CoA changes per second per MR would TD support
> compared to OSPF?
Sure. 
Is issue 24 a problem that we want to handle for NEMO?  Or do we leave it all to MANET/OSPF? 

The assumption in TD is that building that tree and only that tree is enough for nested nemo operation with the infrastructure, and can be done quicker than if you use an abstraction that handles more meshing. The implementation delivers an actual proof of that, but if you just look at the flow, TD is part of ND, which happens before the hello protocol even starts.

Pascal