Subject: [lp-wan] Review of draft-toutain-lpwan-ipv6-static-context-hc-00.txt

From: Alexander Pelov <[email-masked]>
Date: Sun, 2 Oct 2016 14:21:52 +0200

Dear Laurent and Ana,

Thanks for submitting a revised version of your draft. You’ll find my review of the document here.

The draft seems much more readable than the previous version, with simplified presentation and examples that illustrate the concepts which are presented. Thank you for taking into account all discussions that took place during the last Technical Session!

Here are my remarks:

You have cited very briefly why 6LoWPAN and RoHC do not fit well LPWAN’s constraints. For the first you’ve provided a reference to draft-minaburo-lpwan-gap-analysis, but I think you should also consider including the work that was developed in draft-gomez-lpwan-ipv6-analysis-00. On the RoHC applicability, the draft in its state is quite vague on the details. Here again, I think that adding a reference to the draft-minaburo-lpwan-rohc-applicability document would benefit the understanding of the topic. An important point to include here is why we cannot simply take RoHC and use statically configured contexts which do not evolve in time.

Having a couple of figures to understand the topologies and the components you have in your draft could be useful for people who have not followed the work until now. Adding some sequence diagrams would also help better illustrate your examples. 

In addition to the graphics, I think it is important to include something like a pseudo-code for the different algorithms you define in the draft (notably the compression and decompression). 

An open question for me is how to encode the contexts on the hosts. Presumably, the Matching Operators (MO) and the Compression/Decompression Functions (CDF) would be some sort of enumeration, so that we should request to setup an IANA registry for them. Here again, how do we issue new MO/CDFs in the future should be a point to take into account. Ideally, these values will not be sent over the air (in most cases), but I believe this should be addressed in the draft. Related point to this one is how to handle Extension Headers. 

The final general remark goes to the order in which rules are tested on the compressor’s side and the way the rules are selected, which could be important when more than one rule matches a packet. This is the case, for example, with a catch-all rule which would not do any compression, but would allow for generic IP flows to go through the LPWAN link. From compression point of view, the obvious solution would be to 
1) test all rules, and select all that match the packet
2) calculate* the length of the compressed packet for every matching rule 
3) choose the rule which produces the smallest packet

*Note that step 2 will not require the systematic compression of the packet, e.g. it seems to me that in most cases you can calculate the resulting packet size form the context. The catch-all statement is something we need to care about, because otherwise there could be dropped packets when no rule matches them. 

Minor remarks:
Figure 5: LSB: in the description (ctxt value OR rcvd value) - the OR is ambiguous (bit-wise or boolean OR)
Figure 6: IPv6 version is 6, not 0.
Figure 8, and all figures with the examples: state explicitly that the "Sent" column is not part of the rule/context. 

On the examples:
I’d like to see an example where the Decompressor is not the destination of the packet. 

Best,
Alexander

> Le 23 sept. 2016 à 09:23, Laurent Toutain <[email-masked]> a écrit :
> 
> Hi,
> 
> We just submitted a new version of SCHC including comments we received. We simplified some parts to have a better explanation of the compression/decompression process. Draft number is -00 since we move the document from 6lpwa to lpwan.
> 
> Laurent and Ana
> 
> 
> 
> ---------- Forwarded message ----------
> From: <[email-masked] <mailto:[email-masked]>>
> Date: Fri, Sep 23, 2016 at 9:18 AM
> Subject: New Version Notification for draft-toutain-lpwan-ipv6-static-context-hc-00.txt
> To: Laurent Toutain <[email-masked] <mailto:[email-masked]>>, Ana Minaburo <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]>, Laurent Toutain <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> A new version of I-D, draft-toutain-lpwan-ipv6-static-context-hc-00.txt
> has been successfully submitted by Laurent Toutain and posted to the
> IETF repository.
> 
> Name:           draft-toutain-lpwan-ipv6-static-context-hc
> Revision:       00
> Title:          LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP
> Document date:  2016-09-23
> Group:          Individual Submission
> Pages:          14
> URL:            https://www.ietf.org/internet-drafts/draft-toutain-lpwan-ipv6-static-context-hc-00.txt <https://www.ietf.org/internet-drafts/draft-toutain-lpwan-ipv6-static-context-hc-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-toutain-lpwan-ipv6-static-context-hc/ <https://datatracker.ietf.org/doc/draft-toutain-lpwan-ipv6-static-context-hc/>
> Htmlized:       https://tools.ietf.org/html/draft-toutain-lpwan-ipv6-static-context-hc-00 <https://tools.ietf.org/html/draft-toutain-lpwan-ipv6-static-context-hc-00>
> 
> 
> Abstract:
>    This document describes a header compression scheme for IPv6, IPv6/
>    UDP based on static contexts.  This technique is especially tailored
>    for LPWA networks and could be extended to other protocol stacks.
> 
>    During the IETF history several compression mechanisms have been
>    proposed.  First mechanisms, such as RoHC, are using a context to
>    store header field values and send smaller incremental differences on
>    the link.  Values in the context evolve dynamically with information
>    contained in the compressed header.  The challenge is to maintain
>    sender's and receiver's contexts synchronized even with packet
>    losses.  Based on the fact that IPv6 contains only static fields,
>    6LoWPAN developed an efficient context-free compression mechanisms,
>    allowing better flexibility and performance.
> 
>    The Static Context Header Compression (SCHC) combines the advantages
>    of RoHC context which offers a great level of flexibility in the
>    processing of fields, and 6LoWPAN behavior to elide fields that are
>    known from the other side.  Static context means that values in the
>    context field do not change during the transmission, avoiding complex
>    resynchronization mechanisms, incompatible with LPWA characteristics.
>    In most of the cases, IPv6/UDP headers are reduced to a small
>    identifier.
> 
>    This document focuses on IPv6/UDP headers compression, but the
>    mechanism can be applied to other protocols such as CoAP.  It will be
>    described in a separate document.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> 
> 
> -- 
> Laurent Toutain 
> +--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
> | Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit :
> | Mob: +33 6 800 75 900    |                                        |
> | Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |  http://class.touta.in <http://class.touta.in/>
> | [email-masked]         | [email-masked]    |
> +--------------------------+----------------------------------------+
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Ana Minaburo <[email-masked]>
Date: Wed, 12 Oct 2016 13:58:05 +0200

Hello Alex, thanks you for your comments, see inside our responses.

> On 02 Oct 2016, at 14:21, Alexander Pelov <[email-masked]> wrote:
> 
> Dear Laurent and Ana,
> 
> You have cited very briefly why 6LoWPAN and RoHC do not fit well LPWAN’s constraints. For the first you’ve provided a reference to draft-minaburo-lpwan-gap-analysis, but I think you should also consider including the work that was developed in draft-gomez-lpwan-ipv6-analysis-00.
(AM) Yes this both references are needed

> On the RoHC applicability, the draft in its state is quite vague on the details. Here again, I think that adding a reference to the draft-minaburo-lpwan-rohc-applicability document would benefit the understanding of the topic.
(AM) yes, it is important

> An important point to include here is why we cannot simply take RoHC and use statically configured contexts which do not evolve in time.
> 
(AM) Well, I think you are modifying RoHC, because RoHC contexts are not static, RoHC makes a classifications of fields where there are an static part and a dynamic part, the static part is only sent at the beginning of the transmission in order to establish the context, then this part is not send any more or at least only when context is lost. So if I take your idea about static context, you can only initialised your context with this static part, but you need to update the dynamic part of the context that change through the compression, and so forth. So you will need to control your RoHC compression with the sequence number that moves in a WLSB window where the littlest size is 4 bits (15 values) so every 15 values you need to move your window and send a bigger packet with 6 or 7 bits. If there is an error you need to send a complete packet. If we do this we are using first order and second order packets that are between 15 to 4 bytes which are big for LPWAN or larger when context is lost. But all this means also that we need to modify the RoHC actual work that is very complex and that I think everybody needs to understand it before trying to use it.

> An open question for me is how to encode the contexts on the hosts. Presumably, the Matching Operators (MO) and the Compression/Decompression Functions (CDF) would be some sort of enumeration, so t…
(AM) Ok, I’m trying to understand your point here. You are asking different things at the same time, let me see if I got all the points. First, for the C/D functions we can discuss how to do them because this can be a SID in the yang model or a IANA reserved value. Second the new MO/CDFs must be addresses in a new document and third if you are referring to IPv6 extensions, I think they could be covered in a new draft where new usage of LPWAN will be described. I hope I've answered  all your questions?

> 3) choose the rule which produces the smallest packet
(AM) I’m not sure this is really a question of standardisation, it is more implementation problem...

> Figure 8, and all figures with the examples: state explicitly that the "Sent" column is not part of the rule/context. 
(AM) I do not see your remark in figure 6, we know that IPv6 is 6 as you see in the example of figure 7. I think that what it is missing is clarify that IPv6 version is 6.

> I’d like to see an example where the Decompressor is not the destination of the packet. 
(AM) The decompressor is never the destination of the packet. LPWAN Application @  is not LC in the context.
> Alexander

Cheers
Ana
> 
>> Le 23 sept. 2016 à 09:23, Laurent Toutain <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> Hi,
>> 
>> | [email-masked] <mailto:[email-masked]>         | [email-masked] <mailto:[email-masked]>    |
>> [email-masked] <mailto:[email-masked]>