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 >
- [lp-wan] re-order header field request Arun
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request weigengyu
- [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request Arun
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request Laurent Toutain
- Re: [lp-wan] re-order header field request Arun
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Arun
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request அருண்பிரபு (arunprabhu)
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Pascal Thubert (pthubert)
- Re: [lp-wan] Fw: re-order header field request weigengyu
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request weigengyu
- [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] lpwan-overview comments Alexander Pelov
- Re: [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] Fw: re-order header field request Arun
- Re: [lp-wan] Fw: re-order header field request Carles Gomez Montenegro
- Re: [lp-wan] Fw: re-order header field request Laurent Toutain
- Re: [lp-wan] lpwan-overview comments Stephen Farrell
- Re: [lp-wan] lpwan-overview comments Stephen Farrell
- Re: [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] lpwan-overview comments Stephen Farrell
- Re: [lp-wan] Fw: re-order header field request Pascal Thubert (pthubert)
- Re: [lp-wan] lpwan-overview comments Alper Yegin
- Re: [lp-wan] lpwan-overview comments Stephen Farrell