Subject: [6tisch] SeqNum definition in RFC8480 (6P)

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 19 Apr 2019 18:05:47 +0200

Hi,

I came across a question in RFC8480 (6P), which looks like an error to
me... Can anybody help? This is about the SeqNum field of the 6P header.

Section 3.2.2 defines SeqNum like this:

[https://tools.ietf.org/html/rfc8480#section-3.2.2]
>   SeqNum:  The sequence number associated with the 6P Transaction.
>         Used to match the 6P Request, 6P Response, and 6P Confirmation
>         of the same 6P Transaction.

So, basically, a response and a confirmation have the same SeqNum
value as the corresponding request. This is very normal.

However, Section 3.4.6.2 says, if a node detect schedule inconsistency
with a received request, the node does a different thing. A response
in this case has a different SeqNum value from the corresponding
request. This is strange...

[https://tools.ietf.org/html/rfc8480#section-3.4.6.2]
>   If the inconsistency is detected during a 6P Transaction (Figure 31),
>   the node that has detected it MUST send back a 6P Response or 6P
>   Confirmation with an error code of RC_ERR_SEQNUM.  In this 6P
>   Response or 6P Confirmation, the SeqNum field MUST be set to the
>   value of the sender of the message (0 in the example in Figure 31).

In Figure 31, Node A receives 6P Response (SeqNum=0, RC_ERR_SEQNUM) in
the last part of the message sequence. But, according to the
definition by Section 3.2.2, Node A doesn't consider the response to
be part of the transaction initiated by 6P Request (SeqNum=88),

[https://tools.ietf.org/html/rfc8480#section-3.4.6.2]
>           +----------+                           +----------+
>           |  Node A  |                           |  Node B  |
>           +----+-----+                           +-----+----+
>      SeqNum=87 |                                       | SeqNum=87
>                |                                       |
>                | 6P Request  (SeqNum=87)               |
>                |-------------------------------------->|
>                |                                L2 ACK |
>                |<- - - - - - - - - - - - - - - - - - - |
>                |                                       |
>                | 6P Response  (SeqNum=87)              |
>                |<--------------------------------------|
>                | L2 ACK                                |
>                | - - - - - - - - - - - - - - - - - - ->|
>                |                                     ==== power-cycle
>                |                                       |
>      SeqNum=88 |                                       | SeqNum=0
>                |                                       |
>                | 6P Request (SeqNum=88)                |
>                |-------------------------------------->| Inconsistency
>                |                                L2 ACK | detected
>                |<- - - - - - - - - - - - - - - - - - - |
>                |                                       |
>                | 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
>                |<--------------------------------------|
>                | L2 ACK                                |
>                | - - - - - - - - - - - - - - - - - - ->|
>
>         Figure 31: Example of Inconsistency Because Node B Resets
>                           (Detected by Node B)

If this is an error, I'm going to file an errata entry. Otherwise, I'd
like to know why Node B in Figure 31 MUST set 0 to SeqNum for the 6P
Response having RC_ERR_SEQNUM. Node A becomes aware of schedule
inconsistency anyway, seeing RC_ERR_SEQNUM in the response.

By the way, the 5th paragraph in Section 3.4.6 supports Section
3.2.2. The response in an example of the paragraph has the same SeqNum
value as the response, which is 0. This is the same case as explained
with Figure 32.

[https://tools.ietf.org/html/rfc8480#section-3.4.6]
>   When node B receives a 6P Request from node A with SeqNum equal to 0,
>   it checks the stored SeqNum for A.  If A is a new neighbor, the
>   stored SeqNum in B will be 0.  The transaction can continue.  If the
>   stored SeqNum for A in B is different than 0, a potential
>   inconsistency is detected.  In this case, B MUST return RC_ERR_SEQNUM
>   with SeqNum=0.  The SF of node A MAY decide what to do next, as
>   described in Section 3.4.6.2.

Or, am I just confused...?

Best,
Yatch

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Mon, 22 Apr 2019 17:34:35 +0200

Hi Yatch,

thanks for your observation. I think that the behaviour is correct as
described in the text. When node B power cycles loses the last seen seqNum.
Its stored value is then 0 and hence when it receives the request responds
with the error and with the stored last seen seqnum (0).

does it make sense?
regards
Xavi

Missatge de Yasuyuki Tanaka <[email-masked]> del dia dv., 19
d’abr. 2019 a les 18:05:

> _______________________________________________
> 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: Yasuyuki Tanaka <[email-masked]>
Date: Tue, 23 Apr 2019 10:49:48 +0200

Hi Xavi,

Thank you for your reply.

On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote:
> When node B power cycles loses the last seen seqNum. Its stored value is then 0 and hence when it receives the request responds with the error and with the stored last seen seqnum (0).
> 
> does it make sense?

I don't think so... Why doesn't Node B just use SeqNum received from Node A for its response?

Node A in Figure 31 would drop the response with SeqNum=0 at 6P layer because it is not considered as part of the transaction started by the request with SeqNum=88.

Best,
Yatch

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Wed, 24 Apr 2019 11:12:24 +0200

Hi Yatch,

thanks for your response. see inline my comments.

Missatge de Yasuyuki Tanaka <[email-masked]> del dia dt., 23
d’abr. 2019 a les 10:49:

> > When node B power cycles loses the last seen seqNum. Its stored value is
> then 0 and hence when it receives the request responds with the error and
> with the stored last seen seqnum (0).
> >
> > does it make sense?
>
> Node A in Figure 31 would drop the response with SeqNum=0 at 6P layer
> because it is not considered as part of the transaction started by the
> request with SeqNum=88.
>

well SeqNum=0 is only possible after a reset or when the node boots. SeqNum
will always be different than 0 except for that occasions. So 6P can be
aware situation happening in the middle of a transaction.

We took that decision as we consider that Node B may have completely lost
the state, which is critical. Probably the option you mention would have
been also possible but we took that direction.

What is the issue you see with this?

> >          of the same 6P Transaction.

regards
X

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 24 Apr 2019 12:24:26 +0200

Hi Xavi,

> What is the issue you see with this?

At least, there is an inconsistency in RFC8480. Here is another example:

https://tools.ietf.org/html/rfc8480#section-3.2.2

rfc8480>   6P Request, 6P Response, and 6P Confirmation messages for a given
rfc8480>   transaction MUST share the same Version, SFID, and SeqNum values.

Such an inconsistency could bring confusion and/or an interoperability issue.

According to you, a response having SeqNum=0 AND RC_ERR_SEQNUM has a special
meaning which is "I've lost all the states completely (due to power-cycle)",
although this is another case we will receive such a response as shown in
Figure 32... Honestly, I'm not sure how valuable it is to know the peer has
performed power-cycle, by the way.

So, if setting 0 to SeqNum of a response is a right thing, I would add some
text to the SeqNum definition in Section 3.2.2, to tell there is an exception. 

Best,
Yatch

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 24 Apr 2019 06:47:58 -0400

Yacht,
          Let me chime in a little bit. Responses below.
Regards,

             Diego

> performed power-cycle, by the way.

As far as I can remember, it is important to know that the peer has
forgotten all the states and has lost his schedule, so all the allocated
cells with that neighbour are currently not valid anymore and should be
wiped from the local schedule.

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 24 Apr 2019 14:45:11 +0200

Thanks, Diego!

I think, if SeqNum=0 has the special meaning, 6P would need to pass a received
SeqNum to a corresponding SF... But, my understandings is that, SeqNum is
maintained only by 6P and not revealed to SFs... An alternative way to tell
a power-cycle event to the peer would have been defining a separate return
code from RC_ERR_SEQNUM.

> On Apr 24, 2019, at 12:47, Prof. Diego Dujovne <[email-masked]> wrote:
> 
> As far as I can remember, it is important to know that the peer has forgotten all the states and has lost his schedule, so all the allocated cells with that neighbour are currently not valid anymore and should be wiped from the local schedule.

Actually, a node having such a peer should remove outdated cells somehow
without having an explicit signaling.

This is not a job of 6P, though. The SF should take care of it. A peer
may move away from the node without sending a CLEAR request. Even if the
peer sends a CLEAR request before moving somewhere, the CLEAR request may
be lost in the air. 

RPL may do something for this case. If a node has some dedicated TX cells to
its parent, and the parent reboots, RPL on the node could notice there is
something wrong with the parent since measured link quality to the parent
is getting worse. Then, parent switch will be performed.

Or, a SF like MSF would try to relocate badly performed cells. Then, it 
receives RC_ERR_SEQNUM from the parent and take actions to resolve the schedule
inconsistency in the same manner as for other scheduling consistency cases.
The node can see whether the peer loses all the states nor not by having a following
COUNT transaction if the SF really wants to know. If the SF always issues a
CLEAR request to a peer which sent RC_ERR_SEQNUM, the SF doesn't care about
the power-cycle event. Another possibility is that the RELOCATE transaction
ends by 6P Timeout. Again, some actions will be taken by the SF.

Best,
Yatch