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

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 5 Oct 2018 12:27:57 +0200

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 <[email-masked]> 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
>

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 6 Oct 2018 04:28:19 +0300

Yasuyuki Tanaka writes:
> 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... 

The frame pending bit operations in TSCH is bit underspecified in the
802.15.4-2015. We do have comment CID 93 about that in the current
letter ballot. The TG4md documents can be found from [1] and there is
consolidated comments from the last letter ballot [2], and from there
you can find the CID 93 that is talking about the frame pending bit on
TSCH.

This rewrite will most likely add some more text there specifying what
link scheduled means, and when to send the pending bit and so on, I
will make sure it also covers the case where there is no ACK.

My guess is that if there is no ACK, then you abort sending further
frames, and move to the normal TSCH operation, i.e., the
retransmission happens using normal rules.

The reason why we do not have ACK, could be:

1) Transmitted frame did not reach recipient. In this case recipient
will time out as it is not receiving any frames in timeslot even when
the frame pending bit was on on previous frame, so it should most
likely stop listening on that channel and resume operations.

2) Transmitted frame did reach other end, but the ACK did not reach
back. In this case the recipient will process the frame, and if that
frame it received has frame pending bit on, it will stay on this
channel for next frame.

The transmitter has no idea which of those two things happened, thus
only safe thing it can do is to abort also and continue normal
schedule.

But, that is just my guess what should happen, I am not sure what
implementations do, and I do not think we have text in standard
describing exactly what to do.

[1] https://mentor.ieee.org/802.15/documents?is_group=04md
[2] https://mentor.ieee.org/802.15/dcn/18/15-18-0433-06-04md-lb150-consolidated-comments.xlsx
-- 
[email-masked]

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Sat, 6 Oct 2018 10:16:39 +0200

Thank you, Tero!

> The TG4md documents can be found from [1] and there is

Yes, I found CID 93. Nice.

> will make sure it also covers the case where there is no ACK.

That is great. It will be helpful!

My question is about a frame loss in the following case:

[at ASN n]
- a transmitter sends a frame having the pending bit on
- the receiver receives the frame and sends backan ACK to the transmitter
- the receiver decides to stay on the same physical channel in the next slot (because "there is no link scheduled")
- the transmitter receives the ACK and decides to send a next frame on the same physical channel in the next slot

[at ASN n+1]
- the transmitter sends the second frame
- the transmitter doesn't receive an ACK; it sees the frame is lost

> only safe thing it can do is to abort also and continue normal

I agree!

My point here is that, it's unclear if the transmitter should start the TSCH retransmission algorithm by the loss of the latter frame. The condition to start the process in the current test is:

   "When a packet is transmitted on a shared link for which an acknowledgment is expected and none is received, the transmitting device shall invoke the TSCH retransmission algorithm." (Section 6.2.5.3 of IEEE 802.15.4-2015)

The latter frame is not transmitted on a shared link nor on a dedicated link. There is no link scheduled :-)

Best,
Yatch

> On Oct 6, 2018, at 3:28, Tero Kivinen <[email-masked]> wrote:
> 
> Yasuyuki Tanaka writes: