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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
