Subject: [Roll] Compressing the PDAO natively

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 26 Jul 2019 12:49:00 +0000

Dear all

This is hopefully the last item of the list of things we discussed at the group and need to follow up on.

At the time we wrote RFC 6550 we thought that compression was out of scope, that we cared about the semantics, and that a 6LoWPAN thing would rapidly come and compress the RPL control plane packets.
We actually did RFC 8138 for the data plane, but the control plane work has not started yet. So for PDAO, the question is, should we keep the RPL tradition of uncompressed specs, or natively propose an RFC 8138 format for the PDAO.

Having a native PDAO format would allow to copy paste the source route header in non-storing PDAO. Would make the messages shorter. Would hint how to do the rest of the RPL control plane compression.
I'm willing to propose an update in that direction, would like to see feedback on the ML.

What do you all think?

Pascal

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Fri, 26 Jul 2019 10:08:13 -0400

Hello Pascal,

As I said during the meeting, having RPL control plane compression would support the nsa-extention draft as well.
If there is room, I am willing to contribute.

Georgios

> On Jul 26, 2019, at 08:49, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Dear all
>  
> I’m willing to propose an update in that direction, would like to see feedback on the ML.
>  
> What do you all think?
>  
> Pascal
> _______________________________________________
> Roll mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jul 2019 16:58:03 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Having a native PDAO format would allow to copy paste the source route
    > header
    > in non-storing PDAO. Would make the messages shorter. Would hint how to do
    > the rest of the RPL control plane compression.

Interesting.

    > What do you all think?

Years ago, I applied GHC to RPL control packets, and I got rather good
results.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Sat, 27 Jul 2019 00:21:02 +0000

Hi,

For control plane it certainly will help if P-DAO’s address list is compressed. There are other candidates also for control plane compression, such as:

1.      Target option compression in DAO. Can 6lo CID be used? Does this result in cross-layer violation (RPL getting info from 6lo)? If we do not intend to do this, then can we use the ‘Compr’ mechanism used in P2P-RPL/AODV-RPL to elide network prefix in Target Option by using DODAGID.

2.      Is it possible to remove network prefix from the parent address information in Transit Information Option in non-storing DAO ?

3.      NSA-extensions parent set address list compression .. as mentioned by Georgios.

4.      Compressing multiple ARTs (AODV-RPL Targets).

We know that IPv6 addresses are primary source of overhead in all RPL control messages. Can we also put general recommendations for addressing fields for any new work?

Also I assume that with PDAO we intend to compress not only the SRVIO but also the VIO used for storing P-DAO and the same scheme will work.

Regards,
Rahul
On Jul 26, 2019, at 08:49, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Dear all

What do you all think?

Pascal
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Sat, 27 Jul 2019 00:25:37 +0000

Hi Michael, Do you have the implementation anywhere? I would like to experiment as well. Thanks

    > What do you all think?

Years ago, I applied GHC to RPL control packets, and I got rather good results.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 27 Jul 2019 10:56:20 -0400

> experiment as well. Thanks

Yes, I have some code... finding it:

   https://github.com/mcr/roll-ghc

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 28 Jul 2019 11:11:28 +0200

>   https://github.com/mcr/roll-ghc

Nice — 82 LOC :-)
(No decompressor included, but that should be even smaller.)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2019 16:23:07 -0400

> Nice — 82 LOC :-) (No decompressor included, but that should be even
    > smaller.)

This went back to when some people wanted to produce "compressed" (abridged,
really) versions of RPL control messages.  I knew that would result in
devices that did not accept uncompressed messages, and major features would
be lost. 

I think that this stupid 82LOC did better on the sample packets than the
abridged version did, and the discussion stopped.  And I didn't use the
compression contexts at all.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [