Re: [lp-wan] Update draft-ietf-lpwan-schc-over-lorawan to draft-04

<dominique.barthel@orange.com> Thu, 02 May 2019 15:12 UTC

Return-Path: <dominique.barthel@orange.com>
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63728120406 for <lp-wan@ietfa.amsl.com>; Thu, 2 May 2019 08:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC4HlBnp4Rfw for <lp-wan@ietfa.amsl.com>; Thu, 2 May 2019 08:12:46 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143BB1203E7 for <lp-wan@ietf.org>; Thu, 2 May 2019 08:12:33 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 44vzJv1Dsfz8svk; Thu, 2 May 2019 17:12:31 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 44vzJv0R33z3wbP; Thu, 2 May 2019 17:12:31 +0200 (CEST)
Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM6E.corporate.adroot.infra.ftgroup ([fe80::d89a:9017:59c2:9724%21]) with mapi id 14.03.0439.000; Thu, 2 May 2019 17:12:30 +0200
From: dominique.barthel@orange.com
To: Olivier Gimenez <ogimenez@semtech.com>
CC: "lp-wan@ietf.org" <lp-wan@ietf.org>
Thread-Topic: [lp-wan] Update draft-ietf-lpwan-schc-over-lorawan to draft-04
Thread-Index: AQHVAPifWlmub1lL5kSXsfgSIf5P/aZX8PmA
Date: Thu, 02 May 2019 15:12:30 +0000
Message-ID: <17398_1556809951_5CCB08DF_17398_165_1_D8F0D53B.609F1%dominique.barthel@orange.com>
References: <24305_1556809591_5CCB0777_24305_188_1_D8F0C81B.60970%dominique.barthel@orange.com>
In-Reply-To: <24305_1556809591_5CCB0777_24305_188_1_D8F0C81B.60970%dominique.barthel@orange.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.3.170325
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_D8F0D53B609F1dominiquebarthelorangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/YQCVTdXn0tn7WvxwTZJ0wR2iFSA>
Subject: Re: [lp-wan] Update draft-ietf-lpwan-schc-over-lorawan to draft-04
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2019 15:12:50 -0000

I forgot one more comment:
- Appendix A: the examples seem to be outdated compared to the text, but I guess you knew that.

Dominique

De : lp-wan <lp-wan-bounces@ietf.org<mailto:lp-wan-bounces@ietf.org>> on behalf of Dominique Barthel <dominique.barthel@orange.com<mailto:dominique.barthel@orange.com>>
Date : Thursday 2 May 2019 17:06
À : Olivier Gimenez <ogimenez@semtech.com<mailto:ogimenez@semtech.com>>
Cc : "lp-wan@ietf.org<mailto:lp-wan@ietf.org>" <lp-wan@ietf.org<mailto:lp-wan@ietf.org>>
Objet : Re: [lp-wan] Update draft-ietf-lpwan-schc-over-lorawan to draft-04

Hello Olivier,

I just went through the new text. Great work!

I have the following comments (in order of appearance in the text). They are mostly editorial, except for one: suggestion to use a 5-bit RuleID for Fragmentation (but still 6-bit RuleID for compression), see below:
- Section 3, Fig 1. We have produced a better figure, we believe, that you could reuse. It's Fig 5 in I-D.ietf-lpwan-ipv6-static-context-hc. The source code is available at https://github.com/lp-wan/ip-compression
- Section 5.2. You don't have to have the same RuleID length for Fragmentation and Compression. Using only 5 bits for Fragmentation Rule ID might save you one byte on the ACK, see below.
- Section 5.5.1: FPortUpShort. I guess you mean "Used when fragmentation is required …"
- Section 5.5.1: There is a formatting problem in the FportUpDefault bullet point (at least in my rendition). "Both rules …" should appear un-indented, I suppose.
- Section 5.5.1: Retransmission and inactivity timer. "At the end of a window the ACK corresponding to this window is transmitted by the network gateway (LoRaWAN application server) in the RX1 or RX2 receive slot of end-device if tiles are missing. If this ACK is not received the end-device sends an all-0 (or an all-1) fragment with no payload to request an ACK retransmission.". It seems to me that you are forcing an ACK-Always behaviour, is this intended? Are you sure you do not want to save on the downlink and use the roll-back possibility of the 4 windows?
- Section 5.5.1.1: "In order to minimize ACK, windows size is set to 0." Do you mean minimizing the size of the ACK or the frequency of occurrence of the ACK? I think this sentence could just be left out.
- Section 5.5.1.1, Fig 6: regarding padding, I think it is "either 7 or 0 bits". If the bitmap gets truncated, then there are 0 bits of padding, by the truncation algorithm. If the bitmap is not truncated, then 1+1+127=129 bits, which requires 7 bits of padding.
- Section 5.5.1.2: "62 available for user". The notion of "user" is very vague. I suggest you write "available for compression".
- Section 5.5.1.2, Fig 8.: "Remaining tile, if any". There can be only one tile in the All-1 fragment.
- Section 5.5.1.2, Fig 9. and 10. Should be merged in one. The -18 version of the SCHC draft does not distinguish All-0 ACK and All-1 ACK anymore. The C bit is always present. Given the other field sizes, padding is "either 7 or 0 bits". You could make it "always 0 bits" by having Rule ID be 5 bits for fragmentation (0b'00000), which would leave 31*2 combinations for SCHC C/D (including one reserved for no matching compression rule), therefore 61 rules available for the "user"/compression.
- Section 5.5.2, RuleID: I guess you mean 62 for the user.
- Section 5.5.2, Fig 14. Padding will always be 0 bits, given the other field sizes.
- Section 5.5.2, Fig 15 and 16. Should be merged in one. C bit always present. A good reason to use RuleID on 5 bits for downlink fragmentation.
- Section 5.5.2.1 and 5.5.2.2: our draft has moved away from the term "ACK Fragment", which was confusing, to "ACK message". Sorry for the moving target!
Best regards

Dominique


De : lp-wan <lp-wan-bounces@ietf.org<mailto:lp-wan-bounces@ietf.org>> on behalf of Olivier Gimenez <ogimenez@semtech.com<mailto:ogimenez@semtech.com>>
Date : Thursday 2 May 2019 11:16
À : "lp-wan@ietf.org<mailto:lp-wan@ietf.org>" <lp-wan@ietf.org<mailto:lp-wan@ietf.org>>
Objet : [lp-wan] Update draft-ietf-lpwan-schc-over-lorawan to draft-04

Dear,

We created an new version 04 of draft-ietf-lpwan-schc-over-lorawan where we defined all required parameters to implement a profile, which is now:

·         Uplink (device->SCHC gateway) uses Ack-on-Error

o   SCHC header can be 1 or 2 bytes

·         Downlink (SCHC gateway->device) uses Ack-Always

o   SCHC header is 1 byte

You can find the document at https://github.com/Acklio/schc-over-lorawan/tree/draft-version-04 and see the commit since April, 04 for a full list of changes.

We plan to update the document to revision 04 by May, the 17th if you agree.

Best regard
Olivier

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.