[lp-wan] retransmission in the last window

Arun <arun@ackl.io> Wed, 16 August 2017 08:50 UTC

Return-Path: <arun@ackl.io>
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 F130613242C for <lp-wan@ietfa.amsl.com>; Wed, 16 Aug 2017 01:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ZuecvF24A5RD for <lp-wan@ietfa.amsl.com>; Wed, 16 Aug 2017 01:50:03 -0700 (PDT)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28751323C8 for <lp-wan@ietf.org>; Wed, 16 Aug 2017 01:50:02 -0700 (PDT)
X-Originating-IP: 192.44.77.204
Received: from [192.168.1.157] (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: arun@acklio.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 583A0FB883; Wed, 16 Aug 2017 10:49:59 +0200 (CEST)
From: Arun <arun@ackl.io>
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Cc: lp-wan <lp-wan@ietf.org>
Message-ID: <820db19f-dbb9-5bd0-3871-63d1ef01910c@ackl.io>
Date: Wed, 16 Aug 2017 10:49:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="6Dil0ADwV7ofe307A872TaMuo8BRqlebE"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/g2spgb8YJPMSE_2qwE3hAmaUhdw>
Subject: [lp-wan] retransmission in the last window
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 16 Aug 2017 08:50:05 -0000

Hi Carles and all, 

Scenario : More than one fragment is lost in the last window of ACK always mode; 
Per my understanding, this is bit different than the retransmission behavior that is observed in non-last window.
Since there can be lesser number of fragments than the window size in the last window the receiver has to validate MIC and send ACK for every received packet.
In other cases(other than the last window), the receiver shall wait until the least CFN of the lost fragments before sending the ACK with bitmap.

example of the expected sequence: (took most part of it from Fig:20 draft-05)

   	 Sender               Receiver
             |-----W=1, CFN=6----->|
             |-----W=1, CFN=5----->|
             |-----W=1, CFN=4--X-->|
             |-----W=1, CFN=3----->|
             |-----W=1, CFN=2--X-->|
             |-----W=1, CFN=1----->|
             |-----W=1, CFN=0----->|
             |<-----ACK, W=1-------|bitmap:11010111
             |-----W=1, CFN=4----->|
             |-----W=1, CFN=2----->|
             |<-----ACK, W=1-------|no bitmap
             |-----W=0, CFN=6----->|
             |-----W=0, CFN=5----->|
             |-----W=0, CFN=4--X-->|
             |-----W=0, CFN=3--X-->|
             |-----W=0, CFN=2--X-->|
             |-----W=0, CFN=7----->|MIC checked
             |<-----ACK, W=0-------|bitmap:11000001
             |-----W=0, CFN=4----->|MIC checked 
             |<-----ACK, W=0-------|bitmap:11100001
	     |-----W=0, CFN=3----->|MIC checked 
             |<-----ACK, W=0-------|bitmap:11100001
	     |-----W=0, CFN=2----->|MIC checked 
	     |<-----ACK, W=0-------|no bitmap
			           (End)

is this the expected behavior? 
if yes, an example in the "Appendix" of the draft and a discussion in "Baseline mechanism" section would be useful (please ignore if it is already planned in 06 version).

Thanks,

-- 
Arunprabhu Kandasamy
arun at ackl.io

2 bis rue de la Châtaigneraie
35510 Cesson-Sévigné 
France 
Phone: +33 (0)2.99.12.24.14