[net2-wg] Fwd: Feedback on TEP 124

[Omprakash Gnawali]

---------- Forwarded message ----------
From: Martin Haenggi <mhaenggi at nd.edu>
Date: Fri, Jan 30, 2009 at 3:08 PM
Subject: Feedback on TEP 124
To: Omprakash Gnawali <gnawali at usc.edu>


Hi Omprakash

Here are our (Daniele's, Peter Vizi's, David Tisza's, and mine) fused
comments on TEP 124.

Best,
Martin

-----------
Definition of Link Quality:

1. In 2.1 you say this is the probability that a packet will be
successfully transmitted.
In 2.2 and 2.3, you say it may be based on RSSI and LQI also. This is
inconsistent.
I suggest to adopt the general definition but specify that in LEEP,
the PRR is used
as the *empirical* probability that a packet will be successfully received.

2. Bidirectional link quality. You take the product of the two PRRs
and explain that
this definition assumes independent link losses. Well, its a
definition, so it does not assume anything.
However, if the product of the link qualities should express the
probability that a packet can
be received *and* successfully ACKed, then this is only true if the
forward and backward
link are independent. Now, in reality, they're quite likely strongly
correlated. Now the question
is if this matters. If the forward transmission is not successful, it
does not matter. If it is, the
reverse one will likely be successful as well. Then the bidirectional
link quality is simply given by the PRR
(over the forward path). Alternatively, the minimum of the two PRRs
could be taken, which would
better account for link asymmetries: For example, if p1=p2=1/2, then
the expected total number
of transmissions for successful roundtrip communication is 4, which is
lower than for p1=1/4 and p2=1,
yet the product is the same. So your metric does not distinguish the
symmetric and asymmetric
cases, but the minimum would, which makes it a better indicator than
the product in many cases.

3. Encoding. The PRR is a real value between 0 and 1. In the TEP it is
an integer between 0 and
255. How is the encoding done? Also there appears to be an
inconsistency with the interface
definition, where it is a two-byte value.

Implementation:

1. You do not specify the time window over which PRR is averaged. If this window
spans the entire period from the initialization of the network until
"now", the PRR is a long-term
average that quite likely has little predictive power over what may
happen in the near future.
Or did you implement a finite time window or a "forgetting factor"?
Probably the latter would
perform better; you essentially give more weight to more recently
transmitted packets. This is
typically done using an exponential. If you have a rough idea about
the coherence times in
the network (i.e., the times over which the short-term PRRs remain
approximately constant),
you can optimize this forgetting factor to get the most up-to-date PRR values.

2. A suggestion: If there is not enough room to fit all Link
Information entries: Alternatively to
the round-robin policy, I could imagine including only the k entries
with the highest values.
If a node is well connected, there is probably no reason to use links
with low PRRs.


Minor Remarks:
- It appears that a detailed description of the LinkEstimator
interface is missing.
- What does the estimator do when asked for the link quality to a node
that is unknown?
- Be consistent with "bi-directional" vs. "bidirectional".