Subject: FW: [seamoby] MANET Critique ( was Yet Another BOF?

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 1 Mar 2001 22:01:15 -0500

This is a cross post in response to recent MANET suggestions by members of
the MIP list.

-----Original Message-----
From: Kulwinder Atwal 
Sent: Thursday, March 01, 2001 8:56 PM
To: 'Charles E. Perkins'
Cc: [email-masked]; Gary Kenward
Subject: RE: [seamoby] MANET Critique ( was Yet Another BOF?

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Thursday, March 01, 2001 3:10 PM
> To: Gary Kenward
> Cc: [email-masked]
> Subject: Re: [seamoby] Yet Another BOF?
> 
 
> Thus, it is easy to understand
> "well, we can make Mobile IP do that"...
> And I don't think it's necessarily an
> unfortunate thing that people are thinking
> about such things.

>  But, on the other hand,
> it's important to avoid protocol bloat and
> unnecessary requirements.  To me that just
> means that good engineering is required.

Using this thought let us take a closer look at your MANET ADOV draft
Introduction.

    AODV allows mobile nodes to respond
    quickly to link breakages and changes in network topology.  The
    operation of AODV is loop-free, and by avoiding the Bellman-Ford
    ``counting to infinity'' problem offers quick convergence when the
    ad hoc network topology changes (typically, when a node moves in the
    network).  When links break, AODV causes the affected set of nodes to
    be notified so that they are able to invalidate the routes using the
    broken link.

    One distinguishing feature of AODV is its use of a destination
    sequence number for each route entry.  The destination sequence
    number is created by the destination for any route information it
    sends to requesting nodes.  Using destination sequence numbers
    ensures loop freedom and is simple to program.  Given the choice
    between two routes to a destination, a requesting node always selects
    the one with the greatest sequence number.

From this I see that you are trying to solve two problems:

Loop-free:
Multiple-Paths:

Unfortunately, I cannot think of an AD HOC network where this is a problem.
Maybe, your intent is to suggest it as a solution for Bluetooth?

There are serveral problems with this:

1. You did not read the Spec before writing the draft.  I recall sending you
a private email in December providing you with a link and requesting that
you read the Spec before commenting further on MANET.  Obviously, you have
not bothered to read it.

2. Bluetooth is a Master-Slave Network.  Master-Slave Networks have been
around for at least twenty years and are well understood.  Take a look at
MODBUS (A General Motors Initiative).

In brief, a Master-Slave Network,

2.1.  All communication is between the Master and a Slave.  Either from the
Master to the Slave, or from the Slave to the Master.
2.2.  The Master MUST transmit first by addressing a particular Slave.
Followed immediately by the particular Slave, and only the particular Slave
responding.
2.3.  The Master may broadcast to the network.  In this special case the
Slaves MUST NOT respond to the broadcast.
2.2.  A Slave MUST NOT communicate directly to another Slave. 

Appling this to Bluetooth:

A.  If a single physical device is logical Slave1 on Piconet1 and logical
Slave2 on Piconet2, applying rule 2.2, it MUST NOT route between logical
Slave1 and logical Slave2. No more loops, or multiple paths.

B.  If a single physical device wishes route between two Piconets it MUST be
a Master in one AND a Slave in the other. 

Therefore, there will be no Loops, and no multiple-Paths.  And no need for
MANET.  MANET is solution is search of a problem.  It hasn't found one in
Bluetooth.

>  But, on the other hand,
> it's important to avoid protocol bloat and
> unnecessary requirements.  To me that just
> means that good engineering is required.

Well put, Charlie.  Lets dump MANET, and all references to it, once and for
all.

- Kulwinder.

> Regards,
> Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 6 Mar 2001 10:11:49 -0800 (PST)

> Maybe, your intent is to suggest it as a solution for Bluetooth?

   []

   I'm sorry, but Bluetooth is not the center of the Universe
   and your characterization of MANET as having no importance
   to anything known seems rather harsh and short-sighted. 
   I've read the TORA draft and it does seem like it has
   some interesting properties given a local routing based
   solution being bandied around. I've not read AODV so
   don't have an specific opinion about it.

   If it doesn't work well for Bluetooth, then
   well, it doesn't work well for Bluetooth. I'm
   not in a position to comment on your analysis,
   but I can tell when babies are being ejected
   with the bathwater.

	    Mike

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 6 Mar 2001 15:32:25 -0500

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 1:12 PM
> To: Kulwinder Atwal
> Cc: 'Charles E. Perkins'; [email-masked]; Gary Kenward

Upon reflection it did seem rather harsh.  What I was hoping for were
examples of ADOV use.

>    don't have an specific opinion about it.

I looked over the TORA draft it seems like a start, although some sections
are missing like security.  But, perhaps security can be dealt with by other
means.

What I am really afraid of is, us getting into a MANET rathole without some
technology examples for us to test  MANET approaches on.  Maybe 802.11 is
another candidate.

---

From: Nitin H Vaidya <[email-masked]>
Date: Tue, 6 Mar 2001 17:46:06 -0600 (CST)

>> From [email-masked] Tue Mar  6 15:45:03 2001
  >> 
  >> What I never understood is why didn't Bluetooth just pick one of the MANET
  >> ad hoc routing standards and  and run with it?

I guess partly because, without some changes, these protocols won't
necessarily work on BlueTooth. I am no BlueTooth expert, but
as I understand, different piconets in vicinity of each other
operate on different "channels", which is a slightly different
environment than the single channel environment used in evaluating
the typical MANET proposals. So, at least, some caution is called for.

Besides, perhaps more importantly, it is not obvious (to me) that the
mobility scenarios that MANET working group tends to worry about most 
terribly relevant to the typical applications of BlueTooth.
As would be intuitive, differences in performance of the various
MANET proposals becomes more interesting when mobility is "high"
(meaning that links tend to break often).

  >> Pick TORA?  Pick AODV?  I don't care. Just run with something.    I guess I am
  >> the
  >> evil bandy abouter, but not without the justification that something scalable
  >> will arive
  >> someday.  My feeling is that we can get a few hops standardized now and
  >> into consumer devices now and not have to wait until the cows come home.
  >> Does the IETF have to move this slow?  Internet time is like watching paint
  >> dry these days...

Before one decides whether it is worth watching the paint dry
or not, it would be good to know whether "typical" BlueTooth networks
will change topology frequently or not. If not, then
you are dealing with a much simpler problem, and may be able to
use/adapt proposals from other IETF routing area working groups
as well.

To put it differently, let us not equate "ad hoc"
with high rate of topology change. When topology change is
infrequent, in my view, routing "overhead" is not as important
an issue, as the "quality" chosen routes.

Cheerio.

- nitin

  >> Thanks,
  >> Phil

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 6 Mar 2001 18:42:10 -0500

Well, here's a look inside the 'sausage factory'.

I raised these very concerns, and many others with a member of the BARB
(Bluetooth Architechure Review Board) over the weekend and yesterday.  The
BARB has similiar responsibilities as the IESG.  It oversees the SIG Working
Groups, sets the technical direction of the SIG and reports directly to the
SIG Board of Directors.

There is no "official SIG position".  Even a Director of the Board, when
speaking publically is giving a personal opinion.  The SIG has no
spokesperson.  If you hear anyone at the BOF talking as if there was an
"official SIG position", please feel free to correct them.  

The WGs have a history of claiming a very wide scope which prevents others
from innovating in that space.
Further, they have in the past, chosen to work in secrecy releasing no more
that some Power Point to most SIG members.  All SIG members are under NDA,
therefore the only reason one can think of for this is the competive
advantage of WG members.  This has been a sore point amoung many SIG
members.

For the first time, yesterday the PAN WG released its technical docs for
review and feedback from all SIG members.  Today, the Printing WG did the
same.

In Phase I (Ethernet over Bluetooth), the PAN WG aimed a mobility within a
piconet.  In Phase II, the PAN WG plans to decide whether to go with a layer
3 approach for mobility outside of a piconet.  I have stated that Phase II
will require changes to IETF protocols, and at least an IP over Bluetooth
solution.  Phase II cannot occur without IETF involvement.  Further, I
stated that the IETF is moving at a faster pace, with a more comprehensive
and robust mobility solution in several WGs, whereas the SIG has just the
PAN WG. Therefore, I proposed that Phase II be done in the IETF.

The BARB view seems to be,"Well the IETF did not have an IP over Bluetooth
solution when the PAN WG was formed."   I pointed out that the IETF is not
capable of reading the minds of the PAN WG and BARB members.  The view in
the BARB seems to be, change will happen when they "see the IETF moving a
direction that fits with Bluetooth". 

I hope you will raise your concerns at the BOF and on the pre-BOF mailing
list.

- Kulwinder.

> Sent: Tuesday, March 06, 2001 3:07 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [seamoby] MANET Critique ( was Yet Another BOF?
> 
> 
> 
> Hello Phil,
> 
> I'd like to suggest a very slight modification to your proposal.
> 
> Why didn't Bluetooth _participate_ in the [manet] work?
> I am 99.99% confident in stating that any of the authors of
> protocols submitted to [manet] would have been delighted
> to respond to design concerns that might have been voiced
> by Bluetooth proponents -- perhaps to the point of redesigning
> the basic protocols as needed.
> 
> Instead, we seem to have been blindsided and then accused
> of being ignorant of their requirements.
> 
> Determining the final outcome of such conflicts is, indeed,
> slightly less quick than watching paint dry -- and not really
> quite as much fun.
> 
> Regards,
> Charlie P.
> 
> 
> 
> 
> [email-masked] wrote:
> > 
> > Sent by:  Michael Thomas <[email-masked]>
> > 
> > To:   Kulwinder Atwal <[email-masked]>
> > cc:   "'Charles E. Perkins'" <[email-masked]>, 
> [email-masked],
> >       Gary Kenward <[email-masked]> (Phil 
> Neumiller/MW/US/3Com)

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 6 Mar 2001 21:25:27 -0500

> From: Phillip Neumiller [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 6:22 PM
> To: Kulwinder Atwal; [email-masked]'; Michael Thomas
> Cc: Kulwinder Atwal; 'Charles E. Perkins'; [email-masked]
> Well I suggested this would be a problem over a year ago.  I 
> guess I was a
> henny penny back then
> saying "Bluetooth is coming and guess what guys its NOT going 
> to be MANET.

A reason that it is Master-Slave, is because of the Frequency Hopping that
it does.
The Master provides the clock that keeps the piconet synchronized to the
Frequency Hopping Sequence. (FHS)
During discovery, the Master sends an FHS packet to a Slave for it to
synchronize to the Master.
A Slave is required re-synchronize its clock on every Master transmission
that is addressed to it, to account for clock drift.  

Each transmission slot is: 625 microseconds.
Clock drift must be better than 20 parts per million.

It makes sense to use the Master transmission not only for data, but for
clock drift compensation as well. 

If a MANET solution is designed for on top of IP, it needs to be free of
link layer specifics.  

Can a timeout independant IP MANET solution be designed that does not
compete with link layer timeouts?

- Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 6 Mar 2001 22:22:33 -0500

>    solution being bandied around. 

I thought about the TORA draft some more.  It is trying to solve the problem
of which way is upstream and which way is downstream by using "heights".  In
a Master-Slave Network a device knows that upstream is toward its Master,
and downstream is toward its Slave.  

In a technology neutral Ad Hoc routing solution the upstream/downstream
problem does not exist.

- Kulwinder.

---

From: Nitin H Vaidya <[email-masked]>
Date: Wed, 7 Mar 2001 09:58:46 -0600 (CST)

hi Theo

  >> From [email-masked] Wed Mar  7 09:28:21 2001
  >> 
  >> > Since piconets have a Master-Slave organization, one can use
  >> > hierarchical routing, where packets are routed to the destination's
  >> > "cluster head" (i.e., Master), and then to the slave. Many such
  >> > hierarchical protocols have been proposed for MANETs, needless
  >> > to say, and one could easily adapt TORA (or AODV, etc.) to optimize
  >> > for such a hierarchy.
  >> 
  >> Master-slave organization (or better point to point to multipoint) is also over
  >> 802.11 at infrastructure mode
  >> This is the case over PCF (no contention) and DCF (with contention). Does that
  >> render a constitute a reason for using MANET protocols
  >> over 802.11 at that mode?

No, it doesn't.
I guess it might be redundant, but useful, to add that
"mobile ad hoc networking (MANET) protocols" are most suited
for "mobile ad hoc networks".

So, if a mobile directly talks only to a fixed basestation, and the
basestations are connected by an infrastrcture network, then (even if it
is 802.11), it is NOT a mobile ad hoc environment. (One can certainly imagine an
ad hoc environment, which also uses an infrastructure when feasible, but that is
not the environment you imply above).

  >> 
  >> What I am trying to say is that there will be two distinct cases for piconets.
  >> 
  >> 1) the case where the Blue(tooth) AP that forwards traffic to the Bluetooth node
  >> (for instance a stereo forwards traffic to some headphone, a laptop forwards traffic
  >> to some cellphone/palm pilot. In that case we would expect the AP to be fixed,
  >> wouldn't we? This is more faithfull to the intent also of a cable interconnect,
  >> which I think people would like to market FIRST if they want their money BACK.

This is how I too thought BlueTooth was supposed to be used, and should/would be
used in initial products. But since there seems to be interest in MANET protocols,
I can only presume that there would be applications that call for other forms of
BlueTooth connectivity, such as in item 2 you describe below.

  >> 
  >> 2) the case where the Blue AP moves independently of the Bluetooth node. In that
  >> case we have two cases
  >>        a) you have ad-hoc mode where both Blue AP and node work over ad-hoc mode
  >> clusterhead scheme and hope for the best if the population of the Blue nodes is
  >> sparse (indoor/inhouse outdoors)
  >>        b) continue on infrastructure mode by making use of fixed-point Blue
  >> relay-APs (for instance the Blue node is near the fridge in the kitchen
  >> and so the Blue node reassociates with the fridge Blue AP so that the traffic does
  >> not go through the PREVIOUS Blue AP.

  >> As far as I can see MANET protocols kick in during the havoc of movement of BOTH the

If these movements are not too frequent, you might get away with good old
link state routing protocols, without having to do anything particularly new.

  >> Blue AP and the Blue node. Why are we jumping into the MANET boat on this list at a
  >> time where the MANET guys are already solving the problem????

One reason you may not want MANET folks to drift along happily is that BlueTooth
is not the same as 802.11, and most MANET protocols lately have been
evaluated assuming 802.11-like MAC, and certain mobility/traffic models.
What looks great in these evaluations may not necessarily be the best bet for
BlueTooth, considering the differences in layer 2, mobility patterns, and
traffic models. So it will be a good idea for the BlueTooth group to provide
inputs to the MANET group.

Regards.

- nitin

  >> Theo
  >> UCL/Mobile systems

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 8 Mar 2001 00:35:31 -0500

> From: Nitin H Vaidya [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 7:28 AM
> To: [email-masked]
> Cc: [email-masked]
> I am afraid you may have misinterpreted TORA (which is, incidentally,
> derived from a very nice paper by Gafni and Bertsekas on
> "link reversal" algorithms).
> Or, perhaps what you mean by ad hoc is different from what TORA
> assumes.
> 
> Your statement may be accurate if all you have is one Master, and its
> slaves talking to each other. But if the network of interest contains
> multiple piconets (hence multiple masters), one would need a protocol
> to route packets between the piconets -- "downstream" is just
> TORAs way of saying "this way to destination D", nothing
> more than that. So, it makes sense to assign downstream
> directions in case of BlueTooth as well. Heights in TORA are just
> a means to decide which way a link points, not an end unto
> themselves.

Consider this:

1. All the Masters are arranged in a tree structure such that each Master
itself is a Slave in the piconet of its Master.  

2. The root of the tree contains a 'Super-Master'.

3. The 'Super-Master' may be an Isolated Mobile Node (no link to an Access
Point).

4. Only the 'Super-Master' may be an a Access Point.

5. Only the 'Super-Master' can attach the entire tree to an Access Point. 

6. Any Mobile Node may leave to join another Access Point, or become an
Isolated Mobile Node, taking any and all of its Slave Nodes that are
attached to it. (its subnet)

7. An Isolated Mobile Node when linking to an Access Point will surrender
its 'Super-Master' Role.

Do we still need TORA?

- Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 8 Mar 2001 17:58:36 -0500

> From: Charlie Perkins [mailto:[email-masked]]
> Sent: Thursday, March 08, 2001 2:17 PM
> To: Nitin H Vaidya
> Cc: [email-masked]; [email-masked]
> Hello,
> Your proposed structure places severe restrictions.  With no loss
> of functionality, or increase in complexity, it would be 
> quite possible
> to let any ad hoc node be an Internet Access Point.
 
Any physical node can be an Internet Access Point.  'Super-Master' just like
'Master' and 'Slave' is a software mode (Role).

- Kulwinder.