Subject: About TBRPF

From: Amir Qayyum <[email-masked]>
Date: Thu, 7 Sep 2000 09:54:19 +0200 (CEST)

Hi Richard,

I have the impression that TBRPF is tuned keeping in view the dual
channel availability (unicast+broadcast), although it works also for a
single, multiple access channel. Does your implementation use
dual-channel radio interfaces ?

Does the single shared channel assumption impacts the protocol ?
While using a single, shared channel, is it possible to avoid overhead
of sending END_OF_BROADCAST message to EACH child individually
(section 5.2.2) while switching from BROADCAST to UNICAST mode, for
the next packet ?  Similarly, before switching from UNICAST to
BROADCAST mode, is it necessary to wait for acknowledgments of all the
unicast packets sent (section 5.2.2) ?

Moreover, while comparing TBRPF with an efficient version of flooding
(section 1, paragraph 5) do you use the model of sending a separate
copy of a packet to each neighbor, for broadcasts (unicast flooding) ?
(where you obtained the performance gain of 85%). How the reliability
of the channel impacts TBRPF ? (Generally, unicast packets are sent
reliably, but not the broadcast packets).

Amir

---

From: Richard <[email-masked]>
Date: Thu, 07 Sep 2000 22:10:15 -0700

Amir,

You ask some interesting questions, and I would like to think 
about them before sending a full response (soon).  For now, 
I will answer the easier ones:

Our implementation uses a single-channel 802.11 interface (WaveLAN).
The UNICAST mode in such a network is still useful when there is
only one intended recipient, since it is easier/cheaper to do reliable 
unicast than reliable broadcast.

Regarding the simulation results (which are from my MOMUC'99 paper)
we used both the unicast model (where a separate copy of each
packet is sent to each neighbor) and the broadcast model (where a 
single copy is sent to all neighbors).  The 85% reduction in overhead 
compared to flooding is for the unicast model.  For the broadcast model 
the reduction was 60%.  We assumed that a link is reliable when it is up, 
so we don't have results for unreliable links.
(TBRPF uses NACKs to achieve reliable link-level broadcast.)

I want to think more about your questions regarding switching between
BROADCAST and UNICAST modes.  One thing I can say now:
When a node switches from BROADCAST mode to UNICAST mode for a particular 
source, it is likely that there is only one child for that source, 
and only that child must be sent the END_OF_BROADCAST message.

Richard