Subject: [Roll] Eliding mechanism in 6550

From: Rahul Jadhav <[email-masked]>
Date: Fri, 27 Sep 2019 15:59:20 +0000

Hello all,

During the interim, we discussed about the eliding mechanism in 6550.
Basically, 6550, allows DIO Configuration Option to be elided for multicast DIO. However, 6550 does not provide any guidelines on how to do it.  We found that under transient network conditions, it was possible that a node may continue to use the stale configuration option without realizing that an updated option is in circulation.
During the interim Pascal/Michael suggested the use of counter to track the freshness of the Config Option. This could further extend to track MOPex and CAP options freshness.

The suggestion was to use the reserved bits in the base DIO message for such a counter.

I was wondering if the DODAGID in the DIO could also be elided under the same guise? Basically the point is to elide all the "static" information which rarely changes.
Clearly this has issues in multi-DODAG networks but it is possible to handle such issues. Considering that this directly results in 16 bytes savings per DIO multicast message, do you think it is worth the effort or if there are other issues?

Regards,
Rahul

---

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Sep 2019 18:30:50 -0400

Rahul Jadhav <[email-masked]> wrote:
    > During the interim Pascal/Michael suggested the use of counter to track
    > the freshness of the Config Option. This could further extend to track
    > MOPex and CAP options freshness.

    > The suggestion was to use the reserved bits in the base DIO message for such a counter.

Yup.

    > I was wondering if the DODAGID in the DIO could also be elided under
    > the same guise? Basically the point is to elide all the "static"
    > information which rarely changes.

    > Clearly this has issues in multi-DODAG networks but it is possible to
    > handle such issues. Considering that this directly results in 16 bytes
    > savings per DIO multicast message, do you think it is worth the effort
    > or if there are other issues?

My question is what are the sizes of the DIOs, and how close are we to
fragmentation already?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 30 Sep 2019 02:19:00 +0000

[RJ] The typical size of DIO is 93 bytes in my simulation framework.
ICMPv6 Hdr: 4B
DIO Base object: 8B
DODAGID: 16B
Config Option: 16B
Prefix Info: 32B
Remaining bytes are IPv6 and lower layer headers.
Attached is the pcap.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 30 Sep 2019 03:47:00 +0000

I would not compress the identification of the message otherwise a FIO for another DODAG me be confused ...

Regards,

Pascal

> Le 30 sept. 2019 à 00:31, Michael Richardson <[email-masked]> a écrit :
> 
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll