Subject: Re: [6tisch] Question about TD

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Mon, 19 Jun 2017 18:13:43 +0200

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-masked]>:

> 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-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
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

---

From: Remy Leone <[email-masked]>
Date: Mon, 19 Jun 2017 16:14:53 +0000

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-masked]>
a écrit :

>>   obj: Check that concurrent transaction cannot request for the same
>> cells in the schedule according to draft-ietf-6tisch-6top-protocol-05
>>   cfg: star
> (+34) 646 633 681 <+34%20646%2063%2036%2081>

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Tue, 20 Jun 2017 08:24:26 +0200

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-masked]>:

>>> 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
>>>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

---

From: Remy Leone <[email-masked]>
Date: Tue, 20 Jun 2017 07:53:18 +0000

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-masked]>
a écrit :

>> 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-masked]> a écrit :
>>
> Hi Remy,
>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 21 Jun 2017 12:05:43 +0200

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-masked]> wrote:

>>>>>     - 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

-- 
_______________________________________

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
_______________________________________