Subject: [lp-wan] Header compression (Re: 6LoWPAN & LPWAN)

From: Carsten Bormann <[email-masked]>
Date: Fri, 25 Mar 2016 07:49:11 +0100

> No doubt about ROHC...  But you can explain better why 6LOWPAN decided to use IPHC stateless compression.

ROHC is designed to provide very good compression of single massive
flows, in particular periodic flows based on RTP on UDP.
These flows are "massive" in that they tend to last for minutes or
longer, carry a dozen to several dozen packets per second, and generally
dwarf any setup overhead that may be associated with them.
They warrant the setup of per-flow context state in each adaptation
layer instance through which they flow (i.e., two instances per IP hop),
which was OK in a 2000's WCDMA network with essentially a single radio hop.

While 6LoWPAN flows may be as "massive" in that they may last for years
and may have several packets per minute, it is less clear that setting
up per-flow state pairs for each of them in each router in a route-over
mesh is viable, at least when constrained routers are involved.
So 6LoWPAN header compression was initially stateless and later enhanced
by "area context state", i.e., state that is set up to be shared by the
entire 6LoWPAN, relatively small, and changing very slowly.

Today's LPWANs are more like the last-hop networks for which ROHC was
designed than the mesh networks that 6LoWPAN addressed.  Also, their
"millibit" characteristics could benefit from the higher compression
rates that per-flow state can enable.  On the other hand, the actual
flows are somewhat different, and the assumption of cheap bidirectional
communication (as needed for ROHC's O-mode or in particular R-mode) may
not hold.  So just using, say, RFC 3095 or RFC 5225 ROHC over LPWAN may
still be far from optimal.  A ROHC profile might be needed that is
optimized for the characteristics of these flows, and is furthermore
optimized to compress CoAP instead of RTP.

On a practical level, the patents that originally have been designed to
read on ROHC may still need a few more years before they run out.  That
is less of a problem in an LTE context, where implementations already
need to be in a patent pool, but it might be for more general Internet
applications of LPWAN technology.  (I am not going to discuss validity
or applicability of specific patents, and I request that this list not
be abused for such a discussion.)

In summary, 6LoWPAN header compression (including area context state)
certainly is applicable to (read: works in) LPWAN technology.  Whether
one wants to instead pursue per-flow context state and thus ROHC-like
mechanisms to save a few more bytes per packet is up for discussion,
maybe with different results for each specific technology.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Mar 2016 07:24:14 +0000

Hello Carsten:

We'd want the best of both worlds. 6LoWPAN's agility to compress multiple flows and ROHC's capability to compress things down to 1-2 octets all the way to the CoAP space.

What this really means is extend the concept of context to a whole header, reuse ROHC's thinking for the predictable fields, yet keeping a minimal signaling to indicate which context is used.

What I'm getting at is that those devices will probably have a very minimum number of headers that they can actually and repeatedly generate or parse, and these would be compressed better than what IPHC achieves. 

Yet we cannot afford a permanent, on-demand for each new flow, learning phase. We want to remove the reactive learning phase completely from the runtime as the 6BBR does for address resolution. And we probably want to replace it by a proactive form of registration whereby the devices indicates a  table of well-known headers (including URIs) that it can generate and another of the headers that it supports. 

And these could be elided using a context ala ROHC, including the variable part when we can, or compressed to less bits like LSB in a sequence counter. 

But we'd still need to carry a context index like that of IPHC as opposed to the assumption of a continuous flow. What we lose from RoHC with that index and some variable parts, we may save on COAP.

So, neither IPHC nor ROHC but a best of both worlds, IOW proactive, stateful, indexed like IPHC, and capable to compress more, and including variable parts, like ROHC.

Does you want to make the exercise? I'd be really happy to replay our exercise that lead to the final form of 6LoRH if you can free some time in B-A...

Pascal

> -----Original Message-----
> From: lp-wan [mailto:[email-masked]] On Behalf Of Carsten
> Bormann
> Sent: vendredi 25 mars 2016 07:49
> To: Samita Chakrabarti <[email-masked]>
> Cc: [email-masked]; Hannes Tschofenig <[email-masked]>;
> Alexander Pelov <[email-masked]>
> Subject: [lp-wan] Header compression (Re: 6LoWPAN & LPWAN)
> 
> > No doubt about ROHC...  But you can explain better why 6LOWPAN
> decided to use IPHC stateless compression.
> 
> ROHC is designed to provide very good compression of single massive flows,
> in particular periodic flows based on RTP on UDP.
> These flows are "massive" in that they tend to last for minutes or longer,
> carry a dozen to several dozen packets per second, and generally dwarf any
> setup overhead that may be associated with them.
> They warrant the setup of per-flow context state in each adaptation layer
> instance through which they flow (i.e., two instances per IP hop), which was
> OK in a 2000's WCDMA network with essentially a single radio hop.
> 
> and may have several packets per minute, it is less clear that setting up per-
> flow state pairs for each of them in each router in a route-over mesh is
> viable, at least when constrained routers are involved.
> by "area context state", i.e., state that is set up to be shared by the entire
> 6LoWPAN, relatively small, and changing very slowly.
> 
> "millibit" characteristics could benefit from the higher compression rates
> that per-flow state can enable.  On the other hand, the actual flows are
> somewhat different, and the assumption of cheap bidirectional
> still be far from optimal.  A ROHC profile might be needed that is optimized
> for the characteristics of these flows, and is furthermore optimized to
> compress CoAP instead of RTP.
> 
> On a practical level, the patents that originally have been designed to read
> on ROHC may still need a few more years before they run out.  That is less of
> a problem in an LTE context, where implementations already need to be in a
> patent pool, but it might be for more general Internet applications of
> LPWAN technology.  (I am not going to discuss validity or applicability of
> specific patents, and I request that this list not be abused for such a
> discussion.)
> 
> certainly is applicable to (read: works in) LPWAN technology.  Whether one
> wants to instead pursue per-flow context state and thus ROHC-like
> mechanisms to save a few more bytes per packet is up for discussion, maybe
> with different results for each specific technology.
> 
> Grüße, Carsten
> 
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Ana Minaburo <[email-masked]>
Date: Fri, 25 Mar 2016 12:22:30 +0100

Hello Pascal and Carsten,

I think both world were defined out of the scope of LP-WAN networks, we
need something that can reduce the header to less than 1byte, it has to be
energy saved, which means intermittent communications and low bandwidth. I
agree that we can based the solution with the two worlds, but thinking
about this new challenge of size. We can register some prefix - index to
the memory of the device but we need to solve the feasibility of this new
scheme.

In an LP-WAN network, the device will principally communicates with the
gateway (router) it may not do an end to end communication (not all the
sensors but some devices that are less constrained). Then from ROHC, which
is defined for point to point (not routing) links but for multimedia
applications (voice and video = huge amount of packets), it is a good
protocol for what it was defined. We can take some ideas about the
compression algorithms and the classification of fields to create a
context. From IPHC the index is a good solution for global addresses and
for routing, we can include new things for saving energy like

I would like to participate to the definition of this new solution.

Cheers
Ana

On Fri, Mar 25, 2016 at 8:24 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Carsten:
>
> We'd want the best of both worlds. 6LoWPAN's agility to compress multiple
> flows and ROHC's capability to compress things down to 1-2 octets all the
> way to the CoAP space.
>
> What this really means is extend the concept of context to a whole header,
> reuse ROHC's thinking for the predictable fields, yet keeping a minimal
> signaling to indicate which context is used.
>
> What I'm getting at is that those devices will probably have a very
> minimum number of headers that they can actually and repeatedly generate or
> parse, and these would be compressed better than what IPHC achieves.
>
> Yet we cannot afford a permanent, on-demand for each new flow, learning
> phase. We want to remove the reactive learning phase completely from the
> runtime as the 6BBR does for address resolution. And we probably want to
> replace it by a proactive form of registration whereby the devices
> indicates a  table of well-known headers (including URIs) that it can
> generate and another of the headers that it supports.
>
> And these could be elided using a context ala ROHC, including the variable
> part when we can, or compressed to less bits like LSB in a sequence counter.
>
> But we'd still need to carry a context index like that of IPHC as opposed
> to the assumption of a continuous flow. What we lose from RoHC with that
> index and some variable parts, we may save on COAP.
>
> So, neither IPHC nor ROHC but a best of both worlds, IOW proactive,
> stateful, indexed like IPHC, and capable to compress more, and including
> variable parts, like ROHC.
>
> Does you want to make the exercise? I'd be really happy to replay our
> exercise that lead to the final form of 6LoRH if you can free some time in
> B-A...
>
> Pascal
>
> flows,
> longer,
> up per-
> entire
> rates
> optimized
> read
> one
> maybe

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Mar 2016 13:49:15 +0000

Hello Ana,

True enough it’s a new field, but we still need to learn from the art. Arguably, ROHC can compress to one byte, and the issues are elsewhere in the on-demand and continuous flows assumptions. Also we still want to compress when there’s no state, so being able to resort to a 6LoWPAN format as opposed to full text is always welcome. Finally, we could/should think of including CoAP in the compressed headers.

Take care,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ana Minaburo
Sent: vendredi 25 mars 2016 12:23
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; Samita Chakrabarti <[email-masked]>; [email-masked]; Hannes Tschofenig <[email-masked]>; Alexander Pelov <[email-masked]>
Subject: Re: [lp-wan] Header compression (Re: 6LoWPAN & LPWAN)

I think both world were defined out of the scope of LP-WAN networks, we need something that can reduce the header to less than 1byte, it has to be energy saved, which means intermittent communications and low bandwidth. I agree that we can based the solution with the two worlds, but thinking about this new challenge of size. We can register some prefix - index to the memory of the device but we need to solve the feasibility of this new scheme.

In an LP-WAN network, the device will principally communicates with the gateway (router) it may not do an end to end communication (not all the sensors but some devices that are less constrained). Then from ROHC, which is defined for point to point (not routing) links but for multimedia applications (voice and video = huge amount of packets), it is a good protocol for what it was defined. We can take some ideas about the compression algorithms and the classification of fields to create a context. From IPHC the index is a good solution for global addresses and for routing, we can include new things for saving energy like

Cheers
Ana

On Fri, Mar 25, 2016 at 8:24 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Carsten:

Pascal

> From: lp-wan [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Carsten
> Bormann
> To: Samita Chakrabarti <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>;
> Alexander Pelov <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 25 Mar 2016 17:03:29 +0100

Hi Pascal,

I think we are on the same page on this question. I get the impression that we’re on a real gap here, where we want ROHC-like behavior in some cases (but much lighter), and 6LoWPAN in others, but also keeping it simple. 

+1 on including CoAP in the compressed headers

Best,
Alexander

> Le 25 mars 2016 à 14:49, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Hello Ana,
>  
> On Fri, Mar 25, 2016 at 8:24 AM, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Carsten:
> 
> > From: lp-wan [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Carsten
> > Bormann
> > To: Samita Chakrabarti <[email-masked] <mailto:[email-masked]>>
> > Cc: [email-masked] <mailto:[email-masked]>; Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>;
> > Alexander Pelov <[email-masked] <mailto:[email-masked]>>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Mar 2016 15:01:49 -0400

Ana Minaburo <[email-masked]> wrote:
    > need something that can reduce the header to less than 1byte, it has to
    > be energy saved, which means intermittent communications and low

If there are 20,000 nodes in an LPWAN (some papers on LPWAN suggest this
number, I have no idea myself), then doesn't the header need to be at least
log_2 (20000) = 15 bits in size to indicate the source address?

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

---

From: Alexander Pelov <[email-masked]>
Date: Sat, 26 Mar 2016 14:25:28 +0100

Dear Michael,

We can simply consider that nodes are on a one-hop network. The L2 address then is sufficient to discriminate between the nodes and you only need to keep track of the number of flows (contexts) per device.

Best,
Alexander

> Le 25 mars 2016 à 20:01, Michael Richardson <[email-masked]> a écrit :
> 
>