IETF Logo Mail Archive

[lp-wan] ACK compression

Olivier Gimenez <ogimenez@semtech.com> Tue, 07 May 2019 16:15 UTC

Return-Path: <ogimenez@semtech.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 96ED8120187 for <lp-wan@ietfa.amsl.com>; Tue, 7 May 2019 09:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 RA2Xz9afOq2l for <lp-wan@ietfa.amsl.com>; Tue, 7 May 2019 09:15:31 -0700 (PDT)
Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC151201F0 for <lp-wan@ietf.org>; Tue, 7 May 2019 09:15:30 -0700 (PDT)
Received: from [67.219.247.53] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-d.us-east-1.aws.symcld.net id 31/64-23357-12FA1DC5; Tue, 07 May 2019 16:15:29 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRWlGSWpSXmKPExsXiofbjua7i+os xBssOCFq8mWXvwOixZMlPpgDGKNbMvKT8igTWjNYZV9kKZrhWHFy7naWBscOmi5GLQ0jgIaPE p9NzWSCc54wS+z8eY4VwdjBKXO84BJTh5GAT0JH4/3wWK4gtIqAuseVREzuILSwgIbGu9z4bR FxWYv7Zv1A1ehJv+vYzgtgsAioSlw/eYgaxeQWsJP7cnAw2k1FATOL7qTVMIDazgLjErSfzwW wJAQGJJXvOM0PYohIvH/9jhbCnMUt87SuAsBUkGuY/Z4HoTZS4uqWNBWK+oMTJmU/AbCEBRYn WaQuZJzAKz0KyYhaSlllIWiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRrOkosz0jJLc xMwcXUMDA11DQyNdC11DIwu9xCrdFL3SYt3UxOISXUO9xPJiveLK3OScFL281JJNjMAoSynga NjBuG55+iFGSQ4mJVFeEfuLMUJ8SfkplRmJxRnxRaU5qcWHGGU4OJQkeA+vBcoJFqWmp1akZe YA4x0mLcHBoyTCqwWS5i0uSMwtzkyHSJ1itOc4sOjhXGaOk99B5Jb7z4DkLhApxJKXn5cqJc7 7YA1QmwBIW0ZpHtxQWHq6xCgrJczLyMDAIMRTkFqUm1mCKv+KUZyDUUmYV3wd0BSezLwSuN2v gM5iAjprXsc5kLNKEhFSUg2MXtfmiNkqlRRtPMttv/JH5HXLsnvC6fdqm/f2Z+r9vKjrImW1c /1P+TMq0yYeXMAg1FXmYZoasUZiof8FoYv5eWd3HbvX42h7myEq43144otUn2NbFy97ebvoSc phlc/uZpemrDBXNveozcru++7a7b00VipSs2F5q5uaClPZ1btK805fFfioxFKckWioxVxUnAg A2vJgUUoDAAA=
X-Env-Sender: ogimenez@semtech.com
X-Msg-Ref: server-13.tower-425.messagelabs.com!1557245728!10298795!1
X-Originating-IP: [72.38.248.231]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received:
X-StarScan-Version: 9.31.5; banners=semtech.com,-,-
X-VirusChecked: Checked
Received: (qmail 8546 invoked from network); 7 May 2019 16:15:29 -0000
Received: from s72-38-248-231.static.datacom.cgocable.net (HELO ca01exedge1.semnet.dom) (72.38.248.231) by server-13.tower-425.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 7 May 2019 16:15:29 -0000
Received: from ca01mail2.semnet.dom (10.2.50.41) by ca01exedge1.semnet.dom (192.168.34.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1034.26; Tue, 7 May 2019 12:15:20 -0400
Received: from ca01mail2.semnet.dom (10.2.50.41) by ca01mail2.semnet.dom (10.2.50.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Tue, 7 May 2019 12:15:24 -0400
Received: from ca01mail2.semnet.dom ([fe80::fdc8:c457:b09e:605d]) by ca01mail2.semnet.dom ([fe80::fdc8:c457:b09e:605d%22]) with mapi id 15.01.1034.026; Tue, 7 May 2019 12:15:24 -0400
From: Olivier Gimenez <ogimenez@semtech.com>
To: "lp-wan@ietf.org" <lp-wan@ietf.org>
Thread-Topic: ACK compression
Thread-Index: AdUE7aZN8HG1sFipRdueWi+g9sViUw==
Date: Tue, 07 May 2019 16:15:24 +0000
Message-ID: <37ef7ce0d1c943e883f5e44d6f19b32e@semtech.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXG9naW1lbmV6XGFwcGRhdGFccm9hbWluZ1wwOWQ4NDliNi0zMmQzLTRhNDAtODVlZS02Yjg0YmEyOWUzNWJcbXNnc1xtc2ctNGYyNzJiOGUtNzBlMy0xMWU5LWI1Y2ItZTRiMzE4NjYzZWUxXGFtZS10ZXN0XDRmMjcyYjhmLTcwZTMtMTFlOS1iNWNiLWU0YjMxODY2M2VlMWJvZHkuaHRtbCIgc3o9IjU5NDIiIHQ9IjEzMjAxNzE5MzIwOTg2MTM1MSIgaD0icmlPNWRJb3djcW5jeW42VzV2RXFMb25zYkpzPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg==
x-originating-ip: [10.144.16.30]
Content-Type: multipart/alternative; boundary="_000_37ef7ce0d1c943e883f5e44d6f19b32esemtechcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/fTdyVahPrQcljGWPaOK-AjT4wK4>
Subject: [lp-wan] ACK compression
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: Tue, 07 May 2019 16:15:34 -0000

Dear,

In the discussion following the draft-ietf-lpwan-schc-over-lorawan v04 with Dominique Barthel we are wondering if an improvement can be made:
In the LoRaWAN profile, from device to SCHC gateway, we tried to minimise the number of windows in order to minimise the number of required downlinks. This has a side effect:  bitmap can be up to 16 bytes.

Let's assume that the profile does not allow to put the last tile in the all-1 message.
Fragment 1:   | ruleId=b'000000 | Dtag=b'0 | W= b'00 | FCN=126 | 4 tiles |               => Receiver's bitmap b'1111 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Fragment 2:   | ruleId=b'000000 | Dtag=b'0 | W= b'00 | FCN=122 | 4 tiles |               => Lost, receiver's bitmap stays unchanged
Fragment 3:   | ruleId=b'000000 | Dtag=b'0 | W= b'00 | FCN=118 | 4 tiles |               => Received, receiver's bitmap becomes b'1111 0000 1111 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Fragment 4:   | ruleId=b'000000 | Dtag=b'0 | W= b'00 | FCN=114 | 4 tiles |                  => Lost, receiver's bitmap stays unchanged
Fragment 5 - All 1:   | ruleId=b'000000 | Dtag=b'0 | W= b'00 | FCN=127 | MIC |         => Received, MIC is wrong, receiver returns ACK
ACK :                | ruleId=b'000000 | Dtag=b'0 | W= b'00 | C=0 | bitmap = b'1111 0000 1111 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 | => Compression will not reduce the bitmap size in this case

What we are thinking is to allow compression of trailing bits also for 0 with the same rule than 1, which will result in the ACK:
Compressed ACK :                | ruleId=b'000000 | Dtag=b'0 | W= b'00 | C=0 | bitmap = b'1111 0000 1111 00

The sender knows how many tiles have been send, so it can resend tiles 122->119 and 114>111. What are your thoughts ?

Thank you

Best regards
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.

v2.23.0 | Report a Bug | By Email