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

[Yasuyuki Tanaka <[e-mail]>]

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