[Tinyos-devel] Re: from longer CTP/LQI experiments

[Omprakash Gnawali]

On Dec 24, 2007 11:18 AM, Jeongyeup Paek <jpaek at enl.usc.edu> wrote:
> Dear all,
>
> I'm not sure whether I am allowed to reply/post to the devel list.
> If I'm not, please let me know.
>
> I've been following the thread and something bugged me a bit.
> You guys are comparing the performance of ctp and lqi as a whole
> (each in lib/net/ctp and lib/net/lqi)
> and I can believe that ctp has better performance than lqi,
> but the discussion seems to only focus on the link estimator part.

This is not true. We are comparing the types of protocols and protocol
as a whole - not just the estimator. The metrics that have been  used
to study them tease out the contributions from various aspects of the
protocol, including, but not limited to link estimation. You mention
estimation and forwarding, there is routing too which is different in
ctp and lqi. I can sort of see where the confusion is coming from.
'lqi', in the context of these discussions, stands for the full
protocol that resides in lib/net/lqi not any particular link
estimation technique.

>
> What I see from the code in the CVS, ctp and lqi not only has different
> link estimator, but has significantly different forwarding engine.
> In particular, I want to point out the 'retransmission backoff'.
> Once a transmission is failed, ctp uses random backoff timer
> for next retransmission. lqi does not, and re-sends immediately.
> Even if you might say that all other parts of ctp-forwarding is
> unique algorithm of ctp, simple backoff before retransmission should
> be a common thing shouldn't it? just as someone wrote down as a comment
>     "// Immediate retransmission is the worst thing to do."
> in ctp/CtrForwardingEngineP.nc, at SubSend.sendDone.
>
> Shouldn't lqi also have same retransmission backoff timer
> for fair comparison?

We would do exactly what you suggest if we were only interested in
comparing the link estimation techniques. We are definitely interested
in understanding the difference in estimation techniques and
estimation parameters (we have been doing this for over a year now)
but we are also interested in understanding the protocols as a whole.
There are different ways to design forwarding and routing protocls -
one way is to do what lqi does, another way is to do what ctp does,
and there are probably many other ways. In the latest discussions you
are reading, we are looking at whole protocols when we compare ctp/lqi
and when we are talking about a's, we are talking about changes in
narrow aspects of link estimation. In the past, we have looked at
other parameters for link estimation and routing for lqi as well as
ctp. Our study is probably not complete and a little sparse on the lqi
side, partly because we have found it difficult to make its
performance consistent even though it has its moments.

If you make the change you suggest, your lqi might work better than
the stock lqi. We have done high rate experiments in the past in which
we tweak the retransmission timers and some other aspects of lqi but
most of these new experiments are done at low rates and pkt generation
times are randomized; there is not a whole lot of pkts to send at a
given moment so I doubt that changing the backoff timer will change
things significantly in these experiments. It will probably change
things slightly as suggested by the new understanding on bi-modality
of cc2420 links.

Having said that, if there is a solid evidence of something that is
broken in lqi, it makes sense to fix that.

- om_p