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

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 14 Jun 2018 14:13:17 +0200

Hello all,

Could anyone help me understand correctly the TSCH CSMA-CA
retransmission algorithm described in Section 6.2.5.3 of IEEE
802.15.4-2015, starting from page-64?

I have some questions...:

---

[1] What does it mean exactly by "the backoff window"?

There is no "backoff window" found in Figure 6-6 nor in the latter
part of Section 6.2.5.3...

I think that "the backoff window"indicates BE (Backoff Exponent), but
it's unclear...

[2] Should we reset BE every time retransmission process starts?

Two conditions to reset the backoff window (BE?) are mentioned in page-64:

- "A successful transmission in a shared link resets the backoff window
  to the minimum value."

- "The backoff window is reset to the minimum value if the
  transmission in a dedicated link is successful and the transmit
  queue is then empty."

In page-65, I see another condition if the backoff windows and BE are
the same thing:

- "A device upon encountering a transmission failure in a shared link
  shall initialize the BE to macMinBe."

It seems the former conditions and the latter condition conflict each
other.

I'm not sure, after all the retransmissions for the last frame in
shared links failed, the next retransmission process should reset BE or
not. What about the case when the transmission for the last frame in a
dedicated link was successful but the transmission queue was NOT
empty?

[3] Errors in Figure 6-6

I don't think Figure 6-6 is correct...

- In the frist transmission attempt (the right-most branch):

  o Boxes of "transmit frame" and "transmission acknowledged?" are
    missing after "N" to "TschCca=On?"
    
  o It says transmission fails when NB exceeds macMaxFrameRetries; but
    I think, it would enter the retransmission process instead of
    "Failure". Which is correct?
    
- In the retransmission process without PCA (the middle branch):

  o "NB" is not initialized; should "NB=0" be there along with
    "BE=macMinBe"?
    
  o BE should be updated by "BE=min(BE+1, macMaxBe)" instead of
    "BE=min(BE-1,macMinBe)", shouldn't it?

I didn't look closer the left-most branch (retransmission with PCA), by the
way.

--- 

Thank you for taking the time to read my email!

Best,
Yatch

---

From: Fabrice Théoleyre <[email-masked]>
Date: Thu, 14 Jun 2018 16:30:41 +0200

Hello Yatch,

> it's unclear…

the backoff window is selected randomly between 0 and 2^BE-1. 

> - "A successful transmission in a shared link resets the backoff window

If it corresponds to a retransmission, this means that the previous transmission has failed. 
So, this case does not correspond here.

>  transmission in a dedicated link is successful and the transmit

dedicated links > no collision / no backoff. 
You transmit it without delay 
(NB: you may have the first transmission during a shared link, and its retransmission in a dedicated one)

>  shall initialize the BE to macMinBe."

According to figure 6.6, yes with TSCH: the packet has been dropped, it corresponds to a novel packet, and it enters in the condition "PCA=Y" after the first transmission  

> It seems the former conditions and the latter condition conflict each

they don’t actually correspond to the same thing.
You must make a distinction between shared and dedicated links, and you may use a succession of shared and dedicated links for the same packet (i.e. its different retransmissions)

> dedicated link was successful but the transmission queue was NOT

If I understand correctly the standard, in that case, the dedicated link should not impact the BE value: the next packet will be picked in the queue, and transmitted with the same BE value as previously. 

Probably to combat unfairness: a transmitter with dedicated links would else succeed to transmit packets in its dedicated links => it would reset more frequently its BE  => more bandwidth than the nodes without dedicated links. 

>    "Failure". Which is correct?

This part seems strange. It seems mixing the case "first transmission" and "no ack required". 
First transmission -> no backoff (the current description is correct)
no ack -> the first transmission is considered successful (the transmitter cannot have any feedback). Thus:
     => the box "transmission acknowledged?" is missing
     =>  the arrow after "NB > ** ?" should point to "retransmission?" instead of "Wait for the next TX link"
 
>  o "NB" is not initialized; should "NB=0" be there along with

no, this is a retransmission so, NB cannot be equal to 0 (to my mind)
"NB is the number of times the CSMA-CA algorithm was required to back off while attempting the current transmission"

>    "BE=min(BE-1,macMinBe)", shouldn't it?

+1

I have also the same doubts as you for the figure 6.6….

Best regards,
Fabrice

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 14 Jun 2018 18:06:49 +0200

Thank you, Fabrice!

> the backoff window is selected randomly between 0 and 2^BE-1. 

According to you, the term of "the backoff window" seems to be used as the retransmission backoff or the retransmission backoff wait. If so, I was confused by a sentence in the third paragraph of the section, "A successful transmission in a shared link resets the backoff window to the minimum value."

What is "reset" or the minimum value...?

Perhaps, the backoff window there is meant (2^BE - 1) and its minimum value is (2^macMinBe - 1).

> (NB: you may have the first transmission during a shared link, and its retransmission in a dedicated one)

Yes, that how it works.

> If I understand correctly the standard, in that case, the dedicated link should not impact the BE value: the next packet will be picked in the queue, and transmitted with the same BE value as previ…

Hmm, what if that next packet is not acknowledged in the first attempt? 

Will it use the *same* BE value in the following retransmission as perviously or use macMinBe as described in the standard, which could be different from the BE value used previously...?

> "NB is the number of times the CSMA-CA algorithm was required to back off while attempting the current transmission"

Aha, I see; then we need "NB=0" just after the "Retransmission?" box ;-)

> I have also the same doubts as you for the figure 6.6….

It'd be great if someone is woking on revising the figure... (>_<)

Best,
Yatch

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 14 Jun 2018 18:30:25 +0200

I agree with Fabrice's comments, that's how I read the document.

On Thu, Jun 14, 2018 at 6:07 PM Yasuyuki Tanaka <[email-masked]>
wrote:

> According to you, the term of "the backoff window" seems to be used as the
> retransmission backoff or the retransmission backoff wait. If so, I was
> confused by a sentence in the third paragraph of the section, "A successful
> transmission in a shared link resets the backoff window to the minimum
> value."
>
> > If I understand correctly the standard, in that case, the dedicated link
> should not impact the BE value: the next packet will be picked in the
> queue, and transmitted with the same BE value as previously.
>
> Will it use the *same* BE value in the following retransmission as
> perviously or use macMinBe as described in the standard, which could be
> different from the BE value used previously...?
>
> > "NB is the number of times the CSMA-CA algorithm was required to back
> off while attempting the current transmission"
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
________________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Analog Devices
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
________________________________________

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 14 Jun 2018 23:54:58 +0200

Thank you for your comment, Thomas!

> On Jun 14, 2018, at 18:30, Thomas Watteyne <[email-masked]> wrote:
> 

>> the backoff window is selected randomly between 0 and 2^BE-1. 

I may miss something, but I don't think so....

My understanding right now is:

[basics]
- "the backoff window" means the range between 0 and 2^BE -1 
- "the retransmission backoff wait" (delay before the next retransmission) is chosen randomly in the backoff window
- the minimum value of BE is macMinBE; the minimum backoff window is the range between 0 and 2^macMinBE - 1
- the maximum value of BE is macMaxBE; the maxmum backoff window is the range between 0 and 2^macMaxBE - 1 
- after resetting the backoff window, the length of the backoff windows is 2^macMinBE - 1 long
- only first-attempt transmission (non-retransmission) failures in *shared* cells can trigger the retransmission algorithm

[how the backoff window changes as per page-64]
- the backoff window increases for each consecutive failed transmission in a shared link
- the backoff window is reset by
  <rule-1> a transmission success in a shared link
  <rule-2> a transmission success in a dedicated link, which makes the TX queue empty
- the backoff window is NOT reset by
  <rule-3> a transmission failure a dedicated link
  <rule-4> a transmission success in a dedicated link, which doesn't make the TX queue empty

On page-66, it says, "A device upon encountering a transmission failure in a shared link shall initialize the BE to macMinBe." In other words,

  <rule-5>  the backoff window is reset by a first-attempt transmission failure, a failure of non-retransmission, in a *shared* link

Supposing that there are two frames in the TX queue and the retransmission process for one of the frames ends with a transmission success in a dedicated link, the backoff window could remain larger than 2^macMinBE - 1 <rule-4>. Then, if a device starts another retransmission process for the next frame in the TX queue by a transmission failure in a shared link, the device resets the backoff window <rule-5>. 

I think, what made me confused is that rule-4 part. I couldn't see why the device should keep the backoff window by rule-4. The backoff window isn't used for the first-attempt transmission for the second frame because it's not part of the retransmission algorithm. So, the backoff window is just reset when the retransmission process starts even though the window size is kept by rule-4... 

If rurle-2 and rule-4 ware written as below, it would make sense:

- the backoff window is reset by
  <rule-1> ...
  <rule-2'> a transmission success in a dedicated link, the transmission is for a frame under a retransmission process

- the backoff window is NOT reset by
  <rule-3> ...
  <rule-4'> a transmission success in a dedicated link, the transmission is for a frame which is NOT one under a retransmission process
  <rule-5> ...

However, we don't need rule-2' because the backoff window is reset when starting a retransmission process, anyway.

Yes, I'm still confused a little bit... (>_<)

Best,
Yatch

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 15 Jun 2018 13:35:48 +0200

Yatch,
Would you be able to spend 2min during the 6TiSCH call this afternoon to
summarize and ask for input? I can dedicate some time in the OAB.
@Pat, do you plan to be there?
Thomas

On Thu, Jun 14, 2018 at 11:55 PM Yasuyuki Tanaka <[email-masked]>
wrote:

> - only first-attempt transmission (non-retransmission) failures in
> *shared* cells can trigger the retransmission algorithm
>
> On page-66, it says, "A device upon encountering a transmission failure in
> a shared link shall initialize the BE to macMinBe." In other words,
>
>   <rule-5>  the backoff window is reset by a first-attempt transmission
> failure, a failure of non-retransmission, in a *shared* link
>
> Supposing that there are two frames in the TX queue and the retransmission
> process for one of the frames ends with a transmission success in a
> dedicated link, the backoff window could remain larger than 2^macMinBE - 1
> <rule-4>. Then, if a device starts another retransmission process for the
> next frame in the TX queue by a transmission failure in a shared link, the
> device resets the backoff window <rule-5>.
>
> I think, what made me confused is that rule-4 part. I couldn't see why the
> device should keep the backoff window by rule-4. The backoff window isn't
> used for the first-attempt transmission for the second frame because it's
> not part of the retransmission algorithm. So, the backoff window is just
> reset when the retransmission process starts even though the window size is
> kept by rule-4...
>
>   <rule-2'> a transmission success in a dedicated link, the transmission
> is for a frame under a retransmission process
>
>   <rule-4'> a transmission success in a dedicated link, the transmission
> is for a frame which is NOT one under a retransmission process
>   <rule-5> ...
>
> However, we don't need rule-2' because the backoff window is reset when
> starting a retransmission process, anyway.
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 15 Jun 2018 13:40:36 +0200

Thomas,

> Would you be able to spend 2min during the 6TiSCH call this afternoon to summarize and ask for input? I can dedicate some time in the OAB.

Yes, I will. Thank you!

Yatch

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 15 Jun 2018 13:53:02 +0200

Great, thanks!

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 20 Jun 2018 17:04:35 +0300

> 802.15.4-2015, starting from page-64?

During the 2015 revision process we used quite a lot trying to make
that figure and text correct... And it is quite possible we did not
manage to do it... 

> I think that "the backoff window"indicates BE (Backoff Exponent), but

Backoff window is not very clearly defined in the standard, and as
commented in other emails it is expressed as number of shared links up
to 2^BE-1. It cannot be expressed as time or backup period (as is done
in 6.2.5.1 for regular CSMA-CA) as there is no fixed time for it. How
long this will be depends on the schedule. I.e. if you have only one
shared link in your schedule this is twice as long as what it is if
you have two shared links.

Perhaps we should add some text in standard to explain it better. 

> It seems the former conditions and the latter condition conflict each

As commented already the text in page 65 consider the case where we
are doing initial transmission, not retransmission. This text is
actually unneeded, as the Figure 6-6 already does the resetting of the
BE on each retransmission.

> dedicated link was successful but the transmission queue was NOT

Figure 6-6 do reset BE every time.

> - In the frist transmission attempt (the right-most branch):

This part should not be here at all. This is Retransmission backoff
algorithm, which is only done when doing retranmission, not the
initial transmission.

This is copy of the TSCH part of the Figure 6-5 left side, except it
is is missing the NB = 0 part.

If you read section 6.2.5.2 it says:

	As illustrated in Figure 6-5, when a TSCH device has a packet
	to transmit, it shall wait for a link to the destination
	device.

So the idea is that Figure 6-5 tells how you do CSMA-CA on initial
transmission. It does not include the transmission part of the waiting
for the ack. This also includes how to do initial CSMA-CA for TSCH.
The end result of Figure 6-5 is explained in page 62:

	Figure 6-5 illustrates the steps of the CSMA-CA algorithm. If
	the algorithm ends in “Success,” the MAC is allowed to begin
	transmission of the frame. Otherwise, the algorithm terminates
	with a channel access failure.

So after that figure 6-5 you know the channel is clear and you can
send, then you transmit the frame and wait for Ack. If you do not
receive Ack, and you are using TSCH you go to the section 6.2.5.3 and
start working on the retransmission algorithm. So you should never
really come to the figure 6-6 with frame that is not retransmission,
so the first question "Retransmission" will always return Y...

>     missing after "N" to "TschCca=On?"

This is because it was copied from the CSMA-CA parts of the figure
6-5, and that did not include actual transmission, only to find out if
channel is clear for sending. So ignore that right side of the figure
6-6, and use left side of 6-5 for initial transmission...

The 6.2.5.3 says that Figure 6-6 is only used for retransmission:

	To reduce the probability of repeated collisions when the
	packets are retransmitted, the retransmission backoff
	algorithm shown in Figure 6-6 shall be implemented for shared
	links.

>     "Failure". Which is correct?

No. This is identical than what Figure 6-5 does and this is indeed
correct. I.e., if we fail CCA on the channel we do consider it as a
failure to transmit when using TSCH. As we do not do backoffs in TSCH
and the next retransmission is going to be on the other channel we do
not wait a while and try to do CCA again like we do for Figure 6-5
middle and right parts. In those cases we do CCA for
macMaxCsmaBackoffs times, but with TSCH this is not feasible, so if
CCA fails, we just assume the sending of the frame failed, increment
NB (which has slightly different meaning than in 6-5 here) and try
again.

Note, that in Figure 6-5 the NB is defined as "NB is the number of
times the CSMA-CA algorithm was required to back off while attempting
the current transmission; this value shall be initialized to zero
before each new transmission attempt." In Figure 6-6 the NB also
includes actual failed retransmissions.

>   o "NB" is not initialized; should "NB=0" be there along with

NB was initialized in the Figure 6-5 when we did initial transmission,
and if there was any CCA failures there which caused us to increment
NB, they carry on to Figure 6-6.

>     "BE=min(BE-1,macMinBe)", shouldn't it?

I do remember that we did have multiple versions of this figure with
different formulas there, and all of them were very confusing...

Hmm... it seems we did have sponsor ballot comment i-9 from Pat Kinney
which included part saying:

	8. In box 'NB = NB +1, BE = min(BE-1, macMinBe) change 'BE =
	min(BE-1, macMinBe)' to 'BE = min(BE+1, macMaxBe)' to
	correspond with page 31 text.

And that comment was accepted, but then it was not implemented in the
actual document. So I think you are right that the BE=min(BE+1,
macMaxBe) is right.

> I didn't look closer the left-most branch (retransmission with PCA),
> by the way.

Nobody looks closely on the PCA branch :-)
-- 
[email-masked]

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 20 Jun 2018 16:13:19 +0200

Hello Tero,

Thank you so much for the detailed comments! I'll take time to read your email carefully.

> Nobody looks closely on the PCA branch :-)

Oh.... (>_<)

Best,
Yatch

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 21 Jun 2018 15:41:14 +0200

Hello Tero,

I think I'm very close to the full understanding. Bear with me...

tero> As commented already the text in page 65 consider the case where
tero> we are doing initial transmission, not retransmission.

I see; this would clear my confusion. (note: "page 65" here is a page
number including the cover page, which corresponds to the printed page
number of 64).

So, the text in page 65 uses the term of "transmission" for the two
case: initial transmission and retransmission. In the latter part of
this email, I'll put annotations to each key sentence of section
6.2.5.3 in page 65 (printed-page 64), saying which a sentence refers,
initial transmission or retransmission.

I think, the following topic is the last piece that I don't have a
clear idea of yet.

tero> In those cases we do CCA for macMaxCsmaBackoffs times, but with
tero> TSCH this is not feasible, so if CCA fails, we just assume the
tero> sending of the frame failed, increment NB (which has slightly
tero> different meaning than in 6-5 here) and try again.
tero> ...
tero> Note, that in Figure 6-5 the NB is defined as "NB is the number
tero> of times the CSMA-CA algorithm was required to back off while
tero> attempting the current transmission; this value shall be
tero> initialized to zero before each new transmission attempt." In
tero> Figure 6-6 the NB also includes actual failed retransmissions.
tero> ...
tero> NB was initialized in the Figure 6-5 when we did initial
tero> transmission, and if there was any CCA failures there which
tero> caused us to increment NB, they carry on to Figure 6-6.

Supposing an initial transmission in a shared link fails by CCA, NB is
incremented to 1. Then, should it stay in the CSMA-CA algorithm as
Figure 6-5 explains? Or, if we could take a CCA failure as a
transmission failure, this CCA failure would trigger the
retransmission algorithm with having NB=1. Which is correct?

- (A) CCA failures don't trigger the retransmission algorithm unless
      NB reaches macMaxFrameRetries.

- (B) A CCA failure during a initial transmission process in a shared
      link triggers the retransmission algorithm with keeping the NB
      value, that will be used for retransmissions, unless NB reaches
      macMaxFrameRetries.

I think you meant (B) in your email, which isn't written in the
standard.

From here, I leave key sentences, prefixed with "std>", in page 65
with annotations.

--- key sentences of 6.2.5.3 in page 65, IEEE 802.15.4-2015

   std> When a packet is transmitted on a shared link for which an
   std> acknowledgment is expected and none is received, the
   std> transmitting device shall invoke the TSCH retransmission
   std> algorithm.

This is talking about the initial transmission of a packet.

   std> Subsequent retransmissions may be in either shared links or
   std> dedicated links as retransmission occurs in the next link to
   std> the destination.

This is obviously about retransmissions.

   std> The retransmission backoff wait applies only to the
   std> transmission on shared links.

This is about retransmissions as well.

I believe, an assumption here is that, once the retransmission
algorithm starts for a certain packet, no initial transmissions for
other packets happen in *shared* links until the retransmission
algorithm ends. While I'd like to discuss this further, it's out of
scope of this thread.

   std> There is no waiting for transmission on dedicated links.

This "waiting" means "the retransmission backoff wait". Then, this
sentence talks about retransmission on dedicated links (without SHARED
bit on), although any transmission in dedicated links have no wait,
either.

   std> The retransmission backoff is calculated in the number of
   std> shared transmission links.

Yes, this is an interesting point of this algorithm and optimization
for TSCH.

   std> The backoff window increases for each consecutive failed
   std> transmission in a shared link.

This is about retransmission failures in shared links.

   std> A successful transmission in a shared link resets the backoff
   std> window to the minimum value.

This is about a retransmission success in a shared link. But this
operation is not necessary since the backoff window (or BE) is reset
on the next execution of the retransmission algorithm.

   std> The backoff window does not change when a transmission is a
   std> failure in a dedicated link.

This is talking about any type of transmission failure in a dedicated
link during the retransmission process (algorithm).

   std> The backoff window does not change when a transmission is
   std> successful in a dedicated link and the transmission queue is
   std> still not empty afterwards.

This is confusing, but now I understand what it is trying to say.

A transmission success in a dedicated cell has no impact on the
backoff window (or BE) unless it is a retransmission for a packet
under on-going retransmission process (algorithm).

And, it should be fine to reset the backoff window by a retransmission
success in a dedicated cell even if the transmit queue is NOT empty
afterwards. The length of the TX queue doesn't really matter.

   std> The backoff window is reset to the minimum value if the
   std> transmission in a dedicated link is successful and the
   std> transmit queue is then empty.

This means, if a *retransmission* succeeds in a dedicated cell, the
backoff window (or BE) is reset. This operation is not necessary,
though.

---

Thank you, again!!

Best,
Yatch

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 22 Jun 2018 16:51:40 +0300

> number including the cover page, which corresponds to the printed page

The page numbers I am using is the ones printed on the bottom of the
page, which should match the ones in pdf (i.e., if you jump to page 64
in pdf you end up there). The cover page is not numbered. In this
case, I just copied your page number, which was wrong... I.e., the
text this refers to ("A device upon encountering a transmission failure
in a shared link shall initialize the BE to macMinBe.") is on page 66,
not in page 65.

> Figure 6-5 explains?

Yes.

> Or, if we could take a CCA failure as a transmission failure, this
> CCA failure would trigger the retransmission algorithm with having
> NB=1. Which is correct?

CCA failure is not a transmission failure, as you do not try to
transmit anything, you are trying to find the free channel. Note, that
CCA will NOT fail for other tsch transmissions on the slot, as those
transmissions all start at the same time, thus there is no way to
detect them. CCA failure means there is somebody else using some other
radio technology on the channel.

>       NB reaches macMaxFrameRetries.

CCA failures during the initial transmission do not trigger
retransmission algorithm even when NB reaches macMaxFrameRetries. If
the NB reaches the macMaxFrameRetries, then the whole tranmission
failes with CHANNEL_ACCESS_FAILURE error.

>       value, that will be used for retransmissions, unless NB reaches

Yes.

I.e., if we try 2 times to find clear channel during the initial
operation, and increment NB by two, and then find clear channel to
send, then when we move to the figure 6-6 then NB is 2 and continue
from there.

Every transmission attempt is counted towards NB, and failed CCA in
TSCH is counted as failure. The difference is that during the initial
transmission we take every single shared slot we have and try them,
during retransmission we skip some of them as we do random delay.

So you start from the beginning of 6-5:

   - It is TSCH, we take Y arrow
   - We set NB = 0
   - We wait for next TX link to destination (shared or dedicated)
   - We check if this is shared link
   - Lets assume this was shared link, we go down and do CCA
   - If CCA succeeds, we go out of the figure and send frame
   - If CCA failed, we increment NB to 1
   - If NB was not over macMaxFrameRetries we try again
   - We wait for next TX link to destination (shared or dedicated)
   - We check if this is shared link
   - Lets assume this was shared link, we go down and do CCA
   - Lets assume CCA succeeded this time
   - We go out from the figure 6-5.

Next we send frame out, and wait for ack. If there is no ACK, we go to
the figure 6-6 to do retransmissions:

   - This is retransmission (it is always when we come to this figure)
   - Lets say PCA is not enabled
   - We initialize BE with macMinBe
   - Then we do random delay
   - We check if TschCCA is on, and if so we do another CCA
   - If TschCca is not set we skip CCA, regardless wheter this is
     shared or dedicated link. In initial tranmission we do CCA for
     shared links always, and for dedicated links we check TschCca.
   - If CCA was done and channel was idle, we retransmit frame (with
     new security processing and with new ASN).
   - If we get ACK, we exit the 6-6 and say transmission was
     successful
   - If CCA failed or we did not receive ack we increment NB, it was 1
     when we entered to 6-6, now it will be incremented to 2
   - Then we are supposed to raise BE, but current text in figure does
     not really do that.
   - If NB is still smaller than macMaxFrameRetries we retry
   - We again do random delay
   ...

> I think you meant (B) in your email, which isn't written in the

I think it is clear from the figures 6-5 and 6-6. Note, that figures
in standard are normative. There is some text in section 6.2.5.3 which
is not really clear especially as it uses "transmission failure" when
it means initial transmission failure, but then it uses "Successful
transmission" to mean successful retransmission... 

> algorithm ends. While I'd like to discuss this further, it's out of

This is actually bit vague.

Actually I think the original idea was that there is queue of frames
and we always only try to send the first one. I.e., if I have two
frames one going to A and one to B, and the queue order is so that A
is first, we would wait for either shared link, or dedicated link to
A, but we would skip over dedicated links to B, as it is not head of
the queue.

On the other hand there is no reason why I should not be able to use
dedicated link to B to send the frame to it even when it is not first
in queue. I think this kind of text is explictly left out from the
standard, i.e., there is nothing saying it is allowed, but there is
nothing saying you cannot do it.

This of course means that NB variables needs to be per frame, but on
the otherhand we want the BE to be global, not per frame, and this is
not really reflected in the figure now.

> bit on), although any transmission in dedicated links have no wait,

Yes, it says the same as figure 6-6 say:

	Delay for random (2^BE - 1) shared
	links or until dedicated link

I.e., we wait until we skip over n shared links, or until we find
dedicated link.  

> This is about retransmission failures in shared links.

I think this text conflicts with Figure 6-6. Figure 6-6 modifies BE
every time you have retranmission failure regardless whether it was
failure on shared or dedicated link. I think it should make sense to
do what this text says, i.e., only modify BE when using shared link. 

> on the next execution of the retransmission algorithm.

Yes and no. See below.

> This is confusing, but now I understand what it is trying to say.

This part is not really reflected in the figure 6-6, as it will set BE
as noted above in the beginning of the process. And figure 6-6 do not
differentiate success on dedidated or shared links.

> afterwards. The length of the TX queue doesn't really matter.

I think the idea is that if we have several items in the queue, and
our BE is getting large because we are failing to use the shared
links, we should not lower our BE when we manage to send frame on the
dedicated link, as that does not tell us anything about the shared
link usage. So even if we managed to send last frame using the
dedicated link, we should keep the large BE value as we have not
successfully used shared link, so there is no point of lowering it
yet. 

> backoff window (or BE) is reset. This operation is not necessary,

I think this is trying to say that if we go to the idle state, i.e.,
we have no longer frames going out in queue, then there is no point of
keep the large BE even if we managed to clear the queue using
dedicated cell. I.e., if the queue goes empty we reset everything
related to the retranmission timing.
-- 
[email-masked]

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 22 Jun 2018 17:52:27 +0200

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