Improving%20Opportunistic%20Data%20Dissemination%20via%20Known%20Vector

1
Improving Opportunistic Data Dissemination via
Known Vector

• Jyh-How Huang1, Ying-Yu Chen2, Yi-Chao Chen2,
  Shivakant Mishra3, and Ling-Jyh Chen2
• 1 Department of Electronic Engineering, National
  Taiwan University
• 2 Institute of Information Science, Academia
  Sinica
• 3 Department of Computer Science, University of
  Colorado Boulder

2
Motivation

• Replication is the most popular design choice for
  opportunistic network routing protocols.
• For example, the Epidemic Routing protocol sends
  identical copies of a message over multiple paths
  to mitigate the effects of a single path failure.
• Two encountered nodes may have some messages in
  common.
• It is necessary to avoid sending the messages
  that the other node already has.

3
Motivation (Cont.)

• Intuitively, exchanging meta-messages with
  indices of messages in the buffer can solve the
  problem.
• However, meta-message exchange may become a big
  overhead.
• We propose a new scheme, called Known Ventor
  (KV), to reduce the overhead.

4
Meta-Message

• Meta-message is used to avoid sending duplicate
  messages that the other node already has.
• Most protocols apply a scheme called Summary
  Vector as the meta-message.
• A summary vector comprises all identifiers of the
  messages buffered on the node.
• An identifier of a message is unique for each
  message in the network.
• Lets take the Epidemic Routing protocol as an
  example ?

5
Epidemic Routing

• When two nodes encounter, they exchange the
  summary vector with each other.
• Each node compares the received summary vector to
  its buffer, and then requests the messages that
  are not in its buffer.
• We call the request of messages as Request
  Vector.
• After receiving a request vector, the node
  transmits the requested messages.

6
Example of Epidemic Routing
Define BUFx the set of messages in the buffer
of node x SVx,y the summary vector generated by
node x for node y RVx,y the request vector
generated by node x for node y
Node i Node j
1. Before encounter BUFi M1, M2, M3 BUFj M3, M4, M5
2. Exchange summary vectors SVi,j M1, M2, M3 SVj,i M3, M4, M5
3. Send a request vector and transmit messages RVi,j M4, M5 RVj,i M1, M2
4. After transmission BUFi M1, M2, M3, M4, M5 BUFj M1, M2, M3, M4, M5
7
Our Approach Known Vector

• The idea if a node knows which messages are not
  interesting to the other node, he removes those
  message IDs in advance, and thus reduces the SV
  size.
• A simple solution
• Keep a record about who has the message
• Send the record along with the message

8
The Known Vector Scheme

• In the Known Vector scheme, each message has two
  parts
• the original data
• a known vector
• A known vector is a list of nodes who have
  already known this message.
• Known Vectors of the same message may be
  different on different nodes (i.e., each node has
  its own view of the KVs for each stored message)

9
Why using Known Vector?

• The Known Vector scheme can be considered as a
  pre-processor that removes non-interested
  meta-messages from a Summary Vector.
• Every protocol that implements the Summary Vector
  scheme can apply the Known Vector scheme to
  improve its performance.

10
Procedures of Known Vector (0/4)

• Define
• BUFx the set of messages in the buffer of node x
• SVx,y the summary vector generated by node x for
  node y
• RVx,y the request vector generated by node x for
  node y
• Mk,x the copy of a message Mk resided in node x
• KVMk,x the known vector of Mk,x

11
Procedures of Known Vector (1/4)

• Generate and exchange summary vectorsNode x
  generates SVx,y that contains IDs of the messages
  whose known vectors do not contain node y.
• For example, when node i and j encounter
• - Status of node i BUFiM1, M2, KVM1,im, j,
  n, KVM2,ia, b
• - Status of node j BUFjM3, M1, KVM3,ja,
  KVM1,jm
• - Node i generate SVi,jM2 (Note M1 is not
  included because KVM1,i contains j.)
• - Node j generate SVj,iM3, M1

12
Procedures of Known Vector (2/4)

• 2. Generate and send request vectorsAfter
  receiving SVy,x, node x requests all messages in
  SVy,x but not in BUFx, that is, RVx,y SVy,x
  BUFx
• For the previous example
• - Node i generates RVi,jM3 (Note Node i
  does not request M1.)
• - Node j generates RVj,iM2

13
Procedures of Known Vector (3/4)

• 3. Transmit messages requested3.1) For every
  message Mk transmitted from node x to node y,
  node x duplicates Mk,x as Mk,x including KVMk,x,
  and sends it to node y.3.2) After transmission
  KVMk,x lt- KVMk,x U y Mk,y lt- Mk,x,
  KVMk,y lt- KVMk,x U x
• For the previous example
• - After node i sends M2,i to node j
  KVM2,ia,b,j, KVM2,ja,b,i
• - After node j sends M3,j to node i
  KVM3,ja,i, KVM3,ia,j

14
Procedures of Known Vector (4/4)

• 4. Update known vectorsNode x add y into the
  known vector of every message in the set SVx,y
  RVy,x because node y is supposed to request every
  message in SVx,y unless it already has that
  message.
• For the previous example
• - SVi,j RVj,i
• - SVj,i RVi,j M1 gt KVM1,jm,i

15
Evaluation

• Evaluate the performance on top of Epidemic
  Routing
• Simulator The ONE
• The Opportunistic Network Environment simulator
• A Java-based simulator

16
Evaluation Scenarios

• Use two realistic wireless network traces
• ZebraNet
• iMote

Trace Name ZebraNet iMote
Device N/A iMote
Network Type N/A Bluetooth
Duration(days) 16 3
Devices participating 34 274
Number of contacts 31,693 28,217
Avg Contacts/pair/day 3.53086 0.12574
17
Evaluation Settings

• Messages
• Generated in the first 10 of the simulation time
• Are either 1K bytes or 100 bytes
• With a Poisson rate of 40 seconds/message in
  iMote and 200 seconds/message in ZebraNet
• Transmission rate 240Kbps

18
Evaluation I Infinite Buffer
CDF(cumulative distribution function) of delivery
ratio - In both scenario, the two schemes are
comparable.
19
Evaluation I Infinite Buffer
CDF of overhead / total data transmitted - In
iMote, KV reduces about 16 of overhead - In
ZebraNet, KV reduces about 31 of overhead
20
Evaluation II Finite Buffer

• CDF of delivery ratio
• Message size is fixed at 100 bytes.
• The KV scheme outperforms the SV scheme in all
  test cases, and the performance gain
  increases as the buffer size decreases.
• For example, the performance gain is about 16,
  7, and 3 in the ZebraNet when the buffer is
  20k, 40k, and 60k bytes.

21
Evaluation II Finite Buffer

• CDF of overhead / total data transmitted
• Message size is fixed at 100 bytes.
• The KV scheme is able to reduce traffic
  overhead when comparing with the SV scheme.
• For example, the KV scheme reduces about 77,
  77, and 71 in ZebraNet when the buffer size
  is 20k, 40k, and 60k bytes.

22
Conclusion

• The SV overhead may increase substantially as the
  number of messages buffered on each node
  increases.
• We propose a novel approach, Known Vector, to
  mitigate the overhead.
• The evaluation results show that the two schemes
  are comparable when the buffer is infinite.
• However, when the buffer is constrained, the
  Known Vector scheme is much superior to the
  Summary Vector scheme.

23

• Thanks!
• http//www.iis.sinica.edu.tw/cclljj/
• http//nrl.iis.sinica.edu.tw/