Yasuyuki Tanaka writes:
> 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).
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.
> 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?
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.
> - (A) CCA failures don't trigger the retransmission algorithm unless
> 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.
> - (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.
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
> standard.
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...
> >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.
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.
> 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.
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.
> 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.
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.
> 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.
Yes and no. See below.
> 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.
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.
> 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.
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.
> 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.
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 protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
