Hello Yatch,
> [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…
the backoff window is selected randomly between 0 and 2^BE-1.
> [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."
If it corresponds to a retransmission, this means that the previous
transmission has failed.
So, this case does not correspond here.
> - "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."
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)
> 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."
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
> other.
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)
> 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?
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.
> [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?
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"
> - In the retransmission process without PCA (the middle branch):
>
> o "NB" is not initialized; should "NB=0" be there along with
> "BE=macMinBe"?
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"
> o BE should be updated by "BE=min(BE+1, macMaxBe)" instead of
> "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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
