Re: [6tisch] Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

[Yasuyuki Tanaka <[e-mail]>]

Hi Tero,

I came across another question on the retransmission algorithm. Could you help...?

What should we do when a frame sent in an un-scheduled slot is not acknowledged?

As you know, with the frame pending bit, we can send a frame even if we don't have a cell scheduled at that time (Section 7.2.1.3 of IEEE 802.15.4-2015). While I don't think the back-off wait is necessary in this case, this topic is not covered by IEEE 802.15.4-2015...
 
Thank you!
Yatch

> On Jun 22, 2018, at 17:52, Yasuyuki Tanaka <[e-mail]> wrote:
> 
> Thank you, Tero!!
> 
> tero> I.e., the text this refers to ("A device upon encountering a
> tero> transmission failure in a shared link shall initialize the BE to
> tero> macMinBe.") is on page 66, not in page 65.
> 
> OK, we're on the same page now :-)
> 
> tero> Note, that CCA will NOT fail for other tsch transmissions on the
> tero> slot, as those transmissions all start at the same time, thus
> tero> there is no way to detect them. 
> 
> Right, it won't. This is another interesting point of TSCH. I learned
> this from Thomas 1.5 years ago.
> 
>   https://mailarchive.ietf.org/arch/msg/6tisch/E8IDY4-dkuPMIjD3rh54bGdaQ80
> 
> By the way, it seems I misunderstood what you told me two days ago:
> 
> tero>> if CCA fails, we just assume the sending of the frame failed,
> tero>> increment NB (which has slightly different meaning than in 6-5
> tero>> here) and try again.
> 
> I thought, it meant "CCA failure is treated as a transmission failure
> in *Figure 6-5*". This is wrong. But it does for figure 6-6; CCA
> failure is treated in the same manner for retransmission failure (no ACK)
> in figure 6-6. Oh, I am very clear!
> 
> tero> If TschCca is not set we skip CCA, regardless wheter this is
> tero> shared or dedicated link. In initial tranmission we do CCA for
> tero> shared links always, and for dedicated links we check TschCca.
> 
> That's good to know! I totally overlooked this part!!
> 
> tero> I think it is clear from the figures 6-5 and 6-6. Note, that
> tero> figures in standard are normative.
> 
> Thanks to you, figure 6-5 and 6-6 are my friends now.
> 
> One question for clarification: if a node gets out of the CSMA-CA
> algorithm (figure 6-5) with NB == (macMaxFrameRetries - 1) and doesn't
> receive an ACK to a frame transmitted over a shared link, it enters
> the TSCH Retransmission backoff algorithm (figure 6-6) keeping the NB
> value. Then, this node can attempt only one retransmission at most,
> because NB reaches macMaxFrameRetries by one retransmission failure
> (no ACK or channel busy). This is correct, isn't it?
> 
> And, I'd suggest one correction in figure 6-6.
> 
> tero>> Hmm... it seems we did have sponsor ballot comment i-9 from Pat
> tero>> Kinney which included part saying:
> tero>>
> tero>>        8. In box 'NB = NB +1, BE = min(BE-1, macMinBe) change
> tero>>        'BE = min(BE-1, macMinBe)' to 'BE = min(BE+1, macMaxBe)'
> tero>>        to correspond with page 31 text.
> 
> In fact, 'BE = min(BE+1, macMaxBe)' should be applied if and only if a
> retransmission fails in a shared link. Then, we would need a decision
> box having 'shared link?' above the BE update. If it goes to 'Y', then
> execute 'BE = min(BE+1, macMaxBe)'. Otherwise, keep the current BE
> value.
> 
> tero> On the other hand there is no reason why I should not be able to
> tero> use dedicated link to B to send the frame to it even when it is
> tero> not first in queue. I think this kind of text is explictly left
> tero> out from the standard, i.e., there is nothing saying it is
> tero> allowed, but there is nothing saying you cannot do it.
> 
> To my knowledge, this kind of operation commonly happens in 6TiSCH
> implementations which implement the following protocols:
> 
>  https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-12#section-3.1
>  https://tools.ietf.org/html/draft-chang-6tisch-msf-01#section-2
> 
> tero> This of course means that NB variables needs to be per frame,
> tero> but on the otherhand we want the BE to be global, not per frame,
> tero> and this is not really reflected in the figure now.
> 
> It'd be really great if we could have some text on such a case.
> 
> Here is a little input: MSF allocates dedicated *cells* having SHARED
> bit on, and a node could have multiple frames under retransmission
> processes. I have no idea if having one global BE would be enough for
> this case.
> 
> tero> So even if we managed to send last frame using the dedicated
> tero> link, we should keep the large BE value as we have not
> tero> successfully used shared link, so there is no point of lowering
> tero> it yet.
> 
> Oh, it eventually comes back to one of my first questions :-)
> 
> yatch>>> I'm not sure, after all the retransmissions for the last
> yatch>>> frame in shared links failed, the next retransmission process
> yatch>>> should reset BE or not. What about the case when the
> yatch>>> transmission for the last frame in a dedicated link was
> yatch>>> successful but the transmission queue was NOT empty?
> 
> According to discussions so far and the figures, the answer is that BE
> should always be reset when it enters the retransmission
> algorithm....
> 
> tero> I think this is trying to say that if we go to the idle state,
> tero> i.e., we have no longer frames going out in queue, then there is
> tero> no point of keep the large BE even if we managed to clear the
> tero> queue using dedicated cell. I.e., if the queue goes empty we
> tero> reset everything related to the retranmission timing.
> 
> ...yet, part of this different idea is written in the text, which
> confused me... :-/
> 
> Have a wonderful weekend!
> 
> Best,
> Yatch
>