Subject: summary of response to dumber

From: "Nast, Douglas P" <[email-masked]>
Date: Tue, 8 Jan 2002 14:53:44 -0800

summarizing the response to my earlier comment, repeated below:

"dumber question.  Reverse path forwarding is the RFC-authorize (forget
which at the moment) method for distributing a directed broadcast.  This
relies on a unicast routing protocol that has determined "best" paths, is
simple, yet significantly more efficient than flooding.  Why doesn't it
apply?"

Miguel S. points out that if we are talking about using RPF to distribute
routing data (or maybe solicit it in the case of reactive protocols?) we
have a circular argument, since RFP assumes you have proactively-acquired
routes.   I agree, but Scott was talking about "Manet flooding" to send out
"data", and explicitly NOT routing stuff. 

Fred B. points out that RPF doesn't work well, which I did not know.  (I was
thinking of RFC 922, by the way).  The implication here is that he expects
to scratch Scott's itch using IP multicast. So we need a multicast protocol.
But a bunch of multicast protocols have already been proposed, so if this
were the answer, Scott would presumably not have asked the question.  I
remain confused.  

Richard O. points out that his proactive LSR called TBRPF can easily be
extended to support multicast, and that the underlying mechanism would be
RPF.  I wonder what Fred B. thinks about that?  

I should point out that my interest in RPF comes from the fact that I do NOT
want to integrate a multicast protocol unless forced to, but I DO need to
distribute certain data to everyone in the manet.  RPF seemed like a good
alternative to flooding, since I do have a proactive LSR in hand.  

By way of clarifification, "flooding" to me is sending a packet out on every
interface but the one you received it on.   It generates a lot of duplicates
and wastes a lot of bandwidth.  RPF is appreciably better in theory
(although Fred warns me against it). 

Everybody seems to agree that the answer to the "manet flooding" question is
IP multicast. So the only question is which protocol?

So what's the problem?   

Doug Nast, Boeing

---

From: [email-masked]
Date: Tue, 08 Jan 2002 17:42:30 -0800

> routes.  

I have not yet received Miguel's message, but the fact that this
works (for the original version of TBRPF) despite the "circular argument",
or "chicken-egg paradox" as we called it in our paper, is proved in our
INFOCOM'99 paper on TBRPF.  The main idea is that topology information
from nodes 1 hop away can be used to compute paths to nodes 2 hops away,
which in turn provides each node with topology information from nodes
2 hops away (using RPF), which can be used to compute paths to nodes 
3 hops away, etc.

> were the answer, Scott would presumably not have asked the question.  I

I think the idea is to do network-wide broadcast (called "flooding"
by some) because it is simpler than multicast.  As I mentioned, existing 
IP multicast protocols are not appropriate for highly mobile networks.

> RPF.  

I also pointed out that RPF can be added to any link-state routing
protocol, although this could add significant overhead.
I would call the underlying mechanism of TBRPF a *variation* of
RPF, since we have eliminated the NEW/CANCEL PARENT messages.
This mechanism could also be added to any link-state routing protocol,
without adding *any* message overhead (since parents select themselves).

Richard

---

From: "Lachlan B. Michael" <[email-masked]>
Date: Wed, 09 Jan 2002 12:13:10 +0900 (JST)

ogier> > Fred B. points out that RPF doesn't work well, which I did not know.  (I was
ogier> > thinking of RFC 922, by the way).  The implication here is that he expects
ogier> > to scratch Scott's itch using IP multicast. So we need a multicast protocol.
ogier> > But a bunch of multicast protocols have already been proposed, so if this
ogier> > were the answer, Scott would presumably not have asked the question.  I
ogier> > remain confused.  
ogier> 
ogier> I think the idea is to do network-wide broadcast (called "flooding"
ogier> by some) because it is simpler than multicast.  As I mentioned, existing 
ogier> IP multicast protocols are not appropriate for highly mobile networks.

One possible application where where "flooding" techniques have been
considered because of simplicity in a highly mobile network is vehicle
to vehicle communication. The idea is to be continuously transmitting
data about the state of vehicles to "all" vehicles "nearby". The
condition of "nearby" is usually imposed by very low hop count on the data.

##########################################

Lachlan B. Michael <[email-masked]>

Advanced Telecommunication Laboratory,
SONY Computer Science Laboratories, Inc.
Takanawa Muse Building,
3-14-13 Higashi Gotanda, Shinagawa-ku 
Tokyo 141-0022 JAPAN

Tel:	+81-3-5448-4380
Fax:	+81-3-5448-4968