Remy, Your question raises an important point, about what we are aiming for.
IMO, the TD is there to verify that two independent implementation "work together". That is, in the general/normal case, we can show a working system. Of course, it's possible to go much further and test every possible edge case. This is what I see being done in certification/labeling activities, in which it's not uncommon to see thousands of tests. As we don't have much time in a face-to-face meeting, I think we should focus on "positive testing" (does the system work in the normal scenario) rather than "negative testing" (does the system not break in some egde condition). About TD_6TiSCH_6P_04 (https://bitbucket.org/6tisch/td- 6tisch/src/master/tests_e_6p.yml), I think what we should test is that two child nodes cannot schedule the same cell on the same parent node. This can be done by have child1 schedule a particular cell, then have child2 try to schedule the same. Each 6P transaction completes normally. This is different from the test you described, in which we were trying to create (and test) a race condition: child2 issues a 6P request while child1 hasn't received a 6P response yet. Interesting test of course, but hard to setup and too edge condition IMO for a short F2F meeting. Of course, I understand you are working on F-Interop tools to automate all of these tests, which will radically change the game as we will be able to run through hundreds of tests in no time... so let us know what it's ready to use! We will get a glimpse at the plugtest, right? Thomas On Tue, Jun 20, 2017 at 9:53 AM, Remy Leone <[email protected]> wrote: > I think implementation errors might happen when fine-grained locks will be > introduced: > > Nodes A and B MAY support having two transactions going on at the > same time, one in each direction. Similarly, a node MAY support > concurrent 6P Transactions from different neighbors. In this case, > the cells involved in an ongoing 6P Transaction MUST be locked until > the transaction finishes. For example, in Figure 1, node C can have > a different ongoing 6P Transaction with nodes B and R. In case a > node does not have enough resources to handle concurrent 6P > Transactions from different neighbors it MUST reply with a 6P > Response with return code NORES. In case the requested cells are > locked, it MUST reply to that request with a 6P Response with return > code BUSY. The node receiving BUSY or an NORES MAY implement a retry > mechanism, defined by the SF. > > > Le mar. 20 juin 2017 à 08:24, Xavi Vilajosana Guillen <[email protected]> > a écrit : > >> Hi Remy, >> >> in my way of seeing this, and assuming 6N1 goes first in the transaction, >> 6N2 will receive the BUSY as the resource is locked by 6N1, 6N1 will be >> able to finalize as it started the transaction before 6N2 and locked the >> resources. Note that the request message lock the resources. >> >> I want to hear other view as well about this. >> >> regards, >> X >> >> 2017-06-19 18:14 GMT+02:00 Remy Leone <[email protected]>: >> >>> If it is a concurrent situation it's also likely that 6N1 will receive >>> the BUSY. There is no explicit locking. >>> >>> Le lun. 19 juin 2017 à 18:13, Xavi Vilajosana Guillen < >>> [email protected]> a écrit : >>> >> Hi Remy, >>>> >>>> this is a concurrent situation so both should happen almost at the same >>>> time. The return code to 6N2 is BUSY. >>>> >>>> regards, >>>> X >>>> >>>> 2017-06-19 16:37 GMT+02:00 Remy Leone <[email protected]>: >>>> >>>>> Hello, >>>>> >>>>> I got a question about 6P04: >>>>> >>>>> obj: Check that concurrent transaction cannot request for the same >>>>> cells in the schedule according to draft-ietf-6tisch-6top-protocol-05 >>>>> cfg: star >>>>> ref: IEEE802.15.4-2015, draft-ietf-6tisch-6top-protocol-05 >>>>> pre: >>>>> - The DAGroot sends EBs periodically, with a fast rate (equal to >>>>> 10 sec, according to IEEE802.15.4std), so that the 6N does not need to >>>>> send >>>>> KAs for keeping synchronization. >>>>> - All EB packets are sent on a single frequency. >>>>> - Power on DAGroot. >>>>> - Wait until all 6N join the DAGroot >>>>> seq: >>>>> - s: >>>>> - The 6N1 sends a 6P ADD request to the DAGroot for 2 slots. >>>>> - The candidate list is {4,5}. >>>>> - s: >>>>> - The 6N2 sends a 6P ADD request to the DAGroot for 2 slots. >>>>> - The candidate list is {4,5}. >>>>> - c: >>>>> - Check that the returned code for the operation is BUSY. >>>>> >>>>> Should we add more details about the timing? Because the check step >>>>> seems very imprecise. Is it the 6N2 that get the busy return code? The >>>>> 6N1? >>>>> Do we have answers each time a request is sent? >>>>> >>>>> Best regards >>>>> >>>>> Rémy >>>>> >>>>> _______________________________________________ >>>>> 6tisch mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dr. Xavier Vilajosana >>>> Wireless Networks Lab >>>> >>>> *Internet Interdisciplinary Institute (IN3)Professor* >>>> (+34) 646 633 681 <+34%20646%2063%2036%2081> >>>> [email protected] <[email protected]> >>>> http://xvilajosana.org >>>> http://wine.rdi.uoc.edu >>>> Parc Mediterrani de la Tecnologia >>>> Av Carl Friedrich Gauss 5, B3 Building >>>> 08860 Castelldefels (Barcelona). Catalonia. Spain >>>> [image: Universitat Oberta de Catalunya] >>>> >>>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> >> >> -- >> Dr. Xavier Vilajosana >> Wireless Networks Lab >> >> *Internet Interdisciplinary Institute (IN3)Professor* >> (+34) 646 633 681 <+34%20646%2063%2036%2081> >> [email protected] <[email protected]> >> http://xvilajosana.org >> http://wine.rdi.uoc.edu >> Parc Mediterrani de la Tecnologia >> Av Carl Friedrich Gauss 5, B3 Building >> 08860 Castelldefels (Barcelona). Catalonia. Spain >> [image: Universitat Oberta de Catalunya] >> >> > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech 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
