Re: [lp-wan] need for MAX_ACK_REQUESTS?

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Wed, 19 July 2017 11:58 UTC

Return-Path: <carlesgo@entel.upc.edu>
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 A24AB131CD9 for <lp-wan@ietfa.amsl.com>; Wed, 19 Jul 2017 04:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8rdjWa7m1Jth for <lp-wan@ietfa.amsl.com>; Wed, 19 Jul 2017 04:58:51 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D918131CD8 for <lp-wan@ietf.org>; Wed, 19 Jul 2017 04:58:50 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v6JBwlHK008433; Wed, 19 Jul 2017 13:58:47 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 414431D53C1; Wed, 19 Jul 2017 13:58:46 +0200 (CEST)
Received: from 88.208.109.142 by webmail.entel.upc.edu with HTTP; Wed, 19 Jul 2017 13:58:37 +0200
Message-ID: <c53f65f77e2bef71d2b8598cd4c72dfc.squirrel@webmail.entel.upc.edu>
In-Reply-To: <f06b79ed-9b06-8ba0-79da-d091b9270d4e@ackl.io>
References: <f06b79ed-9b06-8ba0-79da-d091b9270d4e@ackl.io>
Date: Wed, 19 Jul 2017 13:58:37 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Arun <arun@ackl.io>
Cc: lp-wan <lp-wan@ietf.org>, BARTHEL Dominique IMT/OLPS <dominique.barthel@orange.com>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.99.2 at violet
X-Virus-Status: Clean
X-Greylist: Delayed for 00:28:51 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 19 Jul 2017 13:58:47 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/yVmpoH_tXeCLkyhwSA642TCcN2I>
Subject: Re: [lp-wan] need for MAX_ACK_REQUESTS?
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, 19 Jul 2017 11:58:54 -0000

Hi Arun,

Thanks for commenting on this.

Currently, MAX_ACK_REQUESTS applies only to the last fragment in a window,
which can be viewed also as an "ACK request". MAX_FRAG_RETRIES applies to
the previous fragments in the window.

I have been thinking about this several times, and I see two options:

1.- Keep the two parameters. There might be reasons for setting
MAX_ACK_REQUESTS to a higher value than MAX_FRAG_RETRIES. It may be
specially critical to get an ACK (which gives feedback on the delivery of
all fragments in the window), while one might want to be careful regarding
how many times a fragment (from the rest of fragments in the window) is
resent. In addition, it is possible to set the two parameters to the same
value if desired.

2.- Remove MAX_ACK_REQUESTS and have just MAX_FRAG_RETRIES applying to all
fragments.

Which are your (and other) opinions on this?

Thanks,

Carles



> Hi Carles, all,
>
>  Do we still need this variable MAX_ACK_REQUESTS ?
>  MAX_FRAG_RETRIES is going to be the same (during retransmission we only
> send the last fragment of the received bitmap which would be considered
> as ACK REQUEST). correct?
>
>  if this is already discussed in the thread of Dominique's review please
> point me to the same.
>
> thanks,
>
> --
>
> Arunprabhu Kandasamy
> arun at ackl.io