Re: [lp-wan] re-order header field request

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Tue, 20 June 2017 16:02 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 98344131510 for <lp-wan@ietfa.amsl.com>; Tue, 20 Jun 2017 09:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Fk188GYJVjpl for <lp-wan@ietfa.amsl.com>; Tue, 20 Jun 2017 09:02:55 -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 05F0E131AAE for <lp-wan@ietf.org>; Tue, 20 Jun 2017 09:02:00 -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 v5KG1wKY037356; Tue, 20 Jun 2017 18:01:58 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 22D8D1D53C1; Tue, 20 Jun 2017 18:01:57 +0200 (CEST)
Received: from 83.55.156.17 by webmail.entel.upc.edu with HTTP; Tue, 20 Jun 2017 18:01:27 +0200
Message-ID: <ec067ef04c60b3fa38ea4887aa455314.squirrel@webmail.entel.upc.edu>
In-Reply-To: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io>
References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io>
Date: Tue, 20 Jun 2017 18:01:27 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Arun <arun@ackl.io>
Cc: lp-wan <lp-wan@ietf.org>, Ana Minaburo <ana@ackl.io>, Laurent Toutain <laurent@ackl.io>
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: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Tue, 20 Jun 2017 18:01:58 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/jrYbnbYYd83oQwjtKN4Ios1ZFUA>
Subject: Re: [lp-wan] re-order header field request
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: Tue, 20 Jun 2017 16:02:59 -0000

Hi Arun,

Thanks for pointing this out.

Your proposal seems fine to me, except for the (possibly minor) detail
that in your proposal "R" would comprise a number of header fields for the
last fragment that would be different from the number of fields in
previous fragments.

Maybe we could also consider another solution: adding the W bit in the
header of the last fragment of the packet.

I haven't found examples of scenarios where the W bit is actually needed
in the last fragment (i.e. fragment with "all ones" CFN). However, I'm
wondering if there is an actual benefit or a related use case that may
require *not* having a W bit in the last fragment header. (If anyone has
any in mind, please chime in!)

On the other hand, if we have the W bit also in the last fragment header,
header format will be more uniform across all fragments.

Thoughts?

Cheers,

Carles




> Hi all,
> Absence of window bit in the last fragment of the packet makes it tricky
> to unmarshall the header at the receiver.
> As I see it, the receiver up front shall know the length of the CFN
> field depending on the Window size configured but doesn't know to
> anticipate the last fragment unless indicated by CFN.
> So I think,  we need to maintain same order on all fragment headers.
>
> existing;
>
>       		<------------ R ---------->
>                           <--T--> 1 <--N-->
>                +-- ... --+- ... -+-+- ... -+
>                | Rule ID | DTag  |W|  CFN  |
>                +-- ... --+- ... -+-+- ... -+
>
> shall be;
>      		<------------ R ---------->
>                           <--T--> <--N--> 1
>                +-- ... --+- ... -+- ... -+-+
>                | Rule ID | DTag  |  CFN  |W|
>                +-- ... --+- ... -+- ... -+-+
>
> and for the last fragment
>    		<------------ R ---------->
>                           <--T--> <--N-->
>                +-- ... --+- ... -+- ... -+-+
>                | Rule ID | DTag  |  CFN  |MIC
>                +-- ... --+- ... -+- ... -+-+
>
>
> what do you think?
>
>
> thanks,
> Arun
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>