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

[Alexander Pelov <[e-mail]>]

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 <[e-mail]> 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: <[e-mail] <mailto:[e-mail]>>
> 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 <[e-mail] <mailto:[e-mail]>>, Ana Minaburo <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]>, Laurent Toutain <[e-mail] <mailto:[e-mail]>>
> 
> 
> 
> 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: [phone]    | Tel: + 33 2 99 12 7026                 | Visit :
> | Mob: [phone]    |                                        |
> | Fax: [phone]    | Fax: [phone]                  |  http://class.touta.in <http://class.touta.in/>
> | [e-mail]         | [e-mail]    |
> +--------------------------+----------------------------------------+
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan