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 protected]> wrote: > Thank you for your comment, Thomas! > > > On Jun 14, 2018, at 18:30, Thomas Watteyne <[email protected]> > wrote: > > > > I agree with Fabrice's comments, that's how I read the document. > > >> 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 > > -- ________________________________________ 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 ________________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
