Hang Cheng
Tomislav Nad
Mirtcho Spassov
1. TEST PROTOCOL
1.1 Analysis
The protocol can be divided up into three separate phases, the session setup, the contract
transmission, and the data transmission. They will each be analyzed and discussed in
order.
First, the goal of the session setup phase is to accurately determine the minimum power
level necessary for the nodes in the (LCP) least-cost-path to forward the packets and what
nodes make up the LCP. First, in order to for each node to determine the minimum
necessary power level, it will begin transmission of test packets starting at the lowest
power level and repeatedly transmit the same packet with increasing power level until it
reaches the maximum power level. These test packets contain the power level they are
transmitted at. As soon as another node receives the first packet for the particular
session, it will begin doing the same thing. The resulting flood will eventually reach the
destination. As each packet comes in, the destination node will record the power level
they were transmitted at in a matrix. Next, after a set period of time, the destination node
will run Dijistra’s Algorithm to determine the LCP based on the cost matrix. Finally, this
is used to determine the payment to each node on the LCP based on the VCG algorithm.
Therefore, the session setup phase is nothing more than a way of replacing the oracle in
the original VCG algorithm.
There are, however, several important disadvantages to this protocol. Because the
destination node, which took the place of the oracle, must receive all the information
from other nodes in the network, the traffic from each node to the destination must be
encrypted to prevent the manipulation of the data. Otherwise, a node can conceivably
pretend to be another node and make a route seem more expensive than it really is. More
importantly, the free flooding of the network can lead to a few undesirable scenarios.
First, the nodes that participate in the flooding do not get compensated for transmitting
their packets and forwarding packets. Now, suppose that there are many increments in
the power levels. Then each node must send as many packets as there as power levels.
This can be very costly. The nodes can conceivably have only a few coarse-grain power
levels but then they can end up transmitting at power levels higher than what is
necessary. Next, a single malicious node can repeatedly request new sessions with new
destinations nodes and thus be able to cause repeated flooding of the entire network. This
can easily drain all the energy of the nodes and is of special concern because networks
that use this protocol might be doing it to conserve energy. In general, there can be many
instances of unnecessary flooding. For example, if two nodes are relatively close to each
other, the entire network will still be flooded even when the destination already has the
LCP. In addition, every new session results in the flooding of the network even if the
two nodes communicate with each other frequently. Therefore, under some scenarios,
this protocol can drain the energy of non-LCP nodes even without any malicious nodes.
This can be especially damaging for networks that frequently send small amounts of
information. In such cases, the overhead is much greater than the data itself.
1
Hang Cheng
Tomislav Nad
Mirtcho Spassov
Furthermore, if there is any mobility or frequent changes in LCP, this overhead can be
quite prohibitive since LCP discovery is costly to the network as a whole.
Lastly, a somewhat far-fetched scenario can involve the source and destination colluding.
The source can pick “r” such that it is actually a small section of the data it needs to send
to the destination. It initiates the session setup and the packet eventually reaches the
destination, which decrypts the packets and gets “r”. The destination will send out a
contract the LCP. When the contract reaches the source, it will not sign it but simply
regard it as an acknowledgement. This scenario is only really practical if there is only a
very small amount of information to send each time. Since flooding the network is free,
the colluding nodes will not incur any charge.
Next, during the contract transmission phase, each node along the LCP is forwarded
contracts from the destination. Each node along the LCP has an incentive to forward it
until it reaches the source because otherwise transmission will not begin and they will not
get paid. The purpose of these is to inform the nodes the lowest necessary power level
they must use since the destination node is the only node that actually knows which
power level succeed in transmitting the test packets. It also ensures that the source node
can examine and agree on the proposed payment. This phase is very simple and there is
only one apparent problem with this. Suppose that the destination is malicious and
decides to use a path that is not the LCP. The source node has no way of knowing that
there are cheaper paths. Furthermore, there is no incentive for the destination node to be
honest because it does not have to bear the burden of paying for the traffic. In fact, there
might be an incentive for it to be dishonest because it would cost less to use any path it
finds instead of spending the necessary processor cycles to find the LCP. Therefore, this
problem exists even when the destination node is not malicious but simply greedy.
The last phase is data transmission, which addresses three issues. The first issue is
obviously the actual transmission of the data and is easily addressed. The second issue is
the fair compensation of the nodes involved the transmission. The last issue is the
confirmation of successful transmission of the packets and preventing disagreements over
this. The second issue is addressed by having the source include secret information in the
last packet of each block of packets that only the destination can read. This information,
the confirmation, can be used to easily generate a hash but cannot be easily derived from
the resulting hash. When the destination node receives the hash with the last packet, it
decrypts the confirmation and sends it back along the LCP. Each node sends it back
along the LCP to other nodes. Unless the nodes receive the confirmation for the block
they have just forwarded, it will not begin forwarding the next block. Therefore, each
node has an incentive to send the confirmation back so more blocks can be forwarded in
the future. Each node then verifies the confirmation and submits it to the system to
receive payment from the source node if it is the last confirmation received. In regards to
the last issue, suppose if some packets in the (k+1) block has been transmitted but the
confirmation is never received, the nodes that did not receive the confirmation will
submit the contract and the source will be charged as thought the block was successfully
transmitted but the payment is never given to the intermediate nodes. This takes away
2
Hang Cheng
Tomislav Nad
Mirtcho Spassov
any incentive for either party to lie about the receipt of confirmation. In order for this
method to work correctly, it must be assumed that the system will periodically give
money to nodes. Otherwise, a malicious destination node can refuse to send the
confirmation. This will result in the intermediate nodes never receiving any payment and
the source node being deducted money. The net result is money being drained from the
network economy. If a group of malicious destination nodes does this repeatedly without
money being given back to the nodes by the system, all the other nodes will eventually
have a zero balance. This will prevent other nodes from transmitting their traffic and
allow the malicious nodes to dominate the network. Even without malicious nodes,
repeated lost of confirmations can also lead to the draining of the network economy.
However, this assumption also creates a problem. If money is injected into the economy
too quickly, then there is no incentive for the nodes to carry traffic for other nodes
because the money it spent will be replenished anyways. If the money is slowly injected
into the economy, then the above scenario can still happen because of repeated nonreceipts of confirmations or malicious nodes causing the economy to drain faster than it is
replaced.
1.2 Utility
If a node is following the protocol, its utility will vary depending on the number of
control messages it sends, the amount it pays to network for propagation of its data, the
amount of data it receives, and the amount it gets overpaid for forwarding data from other
nodes. For each session, during session setup phase each node (except destination) will
have to use
MAXPOW ER
i
 CONTROLPOW ER * r
i 1
power, where r is number of ROUTEINFO messages node will have to forward.
During contract transmission and data transmission phases, each node on LCP path will
have to forward contract message, data messages, and confirmation messages. For
intermediate nodes, total utility during these phases is
overpayment * M  MAXPOWER * ( k  1)
where overpayment is overpayment node receives for each data packet that it forwards, M
is total number of data packets, and k is number of data blocks.
During each session in which a node is destination, it will have to send contract message
through LCP and will have to send confirmations for each data black. Cost to destination
node will be MAXPOWER*(k+1). If a node is sending data, cost to it will be M*p(S, D),
where p(S, D) is payment it gives to network to transfer one data packet to destination D.
Total utility of a node following the protocol is
3
Hang Cheng
Tomislav Nad
Mirtcho Spassov
l * (overpayment * M  MAXPOWER * ( k  1))  i * (
MAXPOW ER
i
 CONTROLPOW ER * R ) 
i 1
 d * MAXPOWER * ( k  1)  s * M * p( S , D )
where l is number of sessions the node is on LCP, i is number of sessions the node is
intermediate node, d is number of sessions the node is destination node, and s is number
of sessions the node is source node. We believe this protocol will work best on sparse
networks and when nodes send large bursts of data. On dense networks and when nodes
send only a few packets at a time, cost of control messages will significantly lower utility
of all nodes in network.
1.3 Computational overhead
Computational overhead in this protocol comes from hashing, checking digital signatures,
encrypting/decrypting and running Dijistra's Algorithm. Hashing and checking digital
signatures are cheap compared to encryption so we ignore them in our analysis.
During setup phase each node in network except S and D has to encrypt 1 message.
However, destination, which has to decrypt n-2 messages, where n is number of nodes in
network, which could be a bottleneck. During data transmission phase, S performs k
encryptions, and D performs k decryptions, where k is number of data blocks.
There are O(n+k) encryptions/decryptions in entire system. However, a cheap encryption
algorithm could be used because data has to be protected only for a relatively short period
of time. Possible bottleneck could be destination node, which has to perform total of n+k
encryptions/decryptions.
1.4 Communication overhead
During session setup phase, each node except destination broadcasts TESTSIGNAL
messages, for total of
( n  1) *
MAXPOW ER
1
i 1
TESTSIGNAL messages in the network, where n is number of nodes in the network.
Total power used for sending these messages is
( n  1) *
MAXPOW ER
i
i 1
Each link in network has a ROUTEINFO message associated with it, which propagates
along control path from link to destination node. There will be total of
 l ( m, D )
m
ROUTEINFO messages in the system, where m is number of links in network, and l(m,
D) is length of control path from link m to destination node D. Total power used by
sending ROUTEINFO messages is
4
Hang Cheng
Tomislav Nad
Mirtcho Spassov
CONTROLPOWER *  l (m, D)
m
In contract transmission phase, l(S, D) messages will be used to send contracts.
MAXPOWER*l(S, D) power will be used to send these messages.
During data transmission phase, total of k*l(S, D) confirmation messages will be sent,
where k is number of data blocks. Network will use total of MAXPOWER*k*l(S, D)
power to send confirmation messages.
Total power used for control messages during entire session is
( n  1)
MAXPOW ER
i
i 1
 CONTROLPOW ER  l ( m, D )  MAXPOWER * ( k  1) * l ( S , D )
m
Assuming MAXPOWER << n, total number of control messages per session is
O(k+n+m2).
We used GloMoSim to measure communication overhead of test protocol. In our
simulated environment, in a dense network of 20 nodes, total of 99.1% of power was
used for communication messages.
2. NEW STIMULATION PROTOCOL
Our proposed modification seeks to address the issue of network flooding, both malicious
and non-malicious, during session setup. Each node will maintain a table of source and
destination node pairs. This table will record the reputation of each pair and start out at a
predetermined level. Every time a node receives a packet from the same pair, the
reputation is decremented. However, each time a node receives a confirmation for
carrying traffic from the source to the destination, it increases the reputation of the pair
by some amount. The reputation is capped at some predetermined, perhaps twice of the
starting level. If the reputation of the source destination pair ever reaches zero, the node
will simply ignore new packets from the source destination pair. The reputation of the
pair will be periodically reset to the beginning level so that if there is a new LCP it will
be discovered. The key assumption here is that LCPs between two nodes are fairly stable
over time with only periodic changes. Once the LCP has been established, it is generally
unnecessary for other nodes to participate in the session setup flooding. Therefore, they
will eventually stop participating in the session setup. However, the nodes along the
LCPs will continue to receive and forward packets because they receive payments from
the source.
In situations without malicious nodes, this modification should decrease the amount of
packets being flooded across the network during session setup. Consider the scenario
when the network first come online and there is a source and a destination node. The
source initiates a session setup by flooding its neighbors. The flood propagates and
eventually reaches the destination. At this point, the reputation of the pair should be
fairly low. Once the LCP is determined and the contracts signed, the source begins
5
Hang Cheng
Tomislav Nad
Mirtcho Spassov
transmitting. When the first block reaches the destination, it sends back the confirmation
and the reputation of the pair increases along the LCP. By the time everything has been
transmitted, the reputation among the nodes along the LCP should be high. When the
source has another series of blocks to send, it initiates session setup again. This time,
however, the flooding is limited largely to the nodes along the previous LCP if the new
session happens soon after. Otherwise, the reputation among the non-LCP nodes would
be reset and the flood would propagate across the network. This is actually desirable
because the chances of a new LCP should increase with time.
Now suppose there is a malicious node using the session setup phase to flood the
network. The node will randomly choose a destination node and initiate session setup.
After the setup, the reputation will be very low. Since the malicious node is not actually
paying any node, his neighbors will stop forwarding packets going to the destination.
Therefore, it must choose a new destination and repeat the process until there is no
destination left and the entire network stops communicating with it. Although the
malicious node is still able to cause some flooding, this modification should result in a
significant drop in the amount of flooding. The node is able to continuously flood the
network without the modifications but can do so for only a limited amount of time after
the modifications. The obvious problem with this is that the limit is proportional to
number of nodes in the network.
3. Results and discussion
We used GloMoSim to test the performance of our protocol versus the original protocol.
The simulated environment consisted of a dense network of twenty nodes, but we expect
our protocol would achieve similar performance increase on sparser or larger networks.
As expected, as nodes learn reputation of other nodes, communication overhead
significantly decreases. After two hours, our protocol needed almost five times less
communication cost, which is control packets times power, than the original protocol. In
the figure below, there was a 5% drop in the ratio of control messages to data messages,
as it went from 11k data/1,216k control to 11k data/262k control.
% of power used for communication messages
100
99
98
without reputation
97
with reputation
96
95
94
15
30
60
120
minutes
6
Hang Cheng
Tomislav Nad
Mirtcho Spassov
While the modifications yielded significant results, there are areas that can be improved
upon. First, instead of an array, the reputation can be recorded using a linked list or a
heap that will slowly decay and restore the reputation. This should decrease the amount
of space needed. More important, the variables such as how much reputation decrease
and increase and how quickly they are restored can be more precisely calculated. These
variables would probably be a function of the network size.
In conclusion, the modifications resulted in a significant reduction in the amount of
packets and power wasted during session setup. The results seem to improve over time.
Therefore, for a network that is constrained by power, it would be worth implementing
and further refining.
7