[Tinyos-devel] [Tinyos Core WG] TEP105: LowPowerListening DutyCycles

[Andreas Koepke]

> >> >> I think TEP 105 should redefine the semantics of cancel, without
>
> the
>
> >> >> clause that requires that the packet is not transmitted yet (or
>
> with
>
> >> >> an error code different than ECANCEL in sendDone?).
> >> >
> >> >[..]
> >> >If it
> >> >is using XMAC-style cyclic sending, then it must return FAIL on
> >> >cancel(), but can signal an early sendDone() with SUCCESS. The
>
> packet
>
> >> >did go out over the air; the chances the receiver got it are much
> >> >lower than if the complete send cycle occurred, but they are
>
> non-zero.
>
> >> Yes, this is in sync with TEP 116. But this implies that a cancel
>
> that
>
> >> returns FAIL does have an effect on the behavior of the radio stack,
> >> which is a bit counterintuitive. Anyway, this appears to be the best
> >> solution so far.
> >
> > To keep the semantics of the TEP, we would have to predict
> > the future whether we will get an ACK and depending on this prediction
>
> return
>
> >either SUCCESS or FAIL to the cancel call.
>
> No. If there has been at least one packet that went out, cancel() will
> return FAIL, since there is a non-zero probability of the message having
> been delivered. But, as a side effect of this failed cancel, the mote
> stops transmitting subsequent packets and signals a sendDone() with
> SUCCESS.
>
> This is, in fact, in compliance with the TEP, because the TEP does not
> say that a failed cancel must not have any side effects with respect to
> transmission. It's a different question whether this is the best way to
> implement cancel() in LPL mode...
>
> Janos

The TEP was written before the cancel implementation worked and before MACs 
with a different rendezvous scheme than preamble sampling became popular.  I 
do not believe it a sacrilege to revise a TEP if new developments demand 
clarification. However, we discuss a corner case here, in my experiments 
practically all calls to cancel happen before the start of the rendezvous 
scheme -- so this discussion is academic. I mean: who writes a protocol that 
relies on the fact that a packet is not transmitted, when it has been given 
to the MAC? There must have been a reason to hand it to the MAC in the first 
place.