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

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Tue, 27 June 2017 14:22 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 EBC10129B40 for <lp-wan@ietfa.amsl.com>; Tue, 27 Jun 2017 07:22:40 -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 wR95n1YlQ2AD for <lp-wan@ietfa.amsl.com>; Tue, 27 Jun 2017 07:22:38 -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 9EECD129B35 for <lp-wan@ietf.org>; Tue, 27 Jun 2017 07:22:37 -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 v5REMRXW049027; Tue, 27 Jun 2017 16:22:27 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id D126E1D53C1; Tue, 27 Jun 2017 16:22:26 +0200 (CEST)
Received: from 83.38.152.35 by webmail.entel.upc.edu with HTTP; Tue, 27 Jun 2017 16:21:55 +0200
Message-ID: <23622a341606ebed36588747e92607b2.squirrel@webmail.entel.upc.edu>
In-Reply-To: <EE6304FA8F854718909CE5544B3F4D50@WeiGengyuPC>
References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <F5C7D3EBA1DD42858C339E13F435F7AC@WeiGengyuPC> <CAEW-XCC6WWU5Y0cG22c7OQriF3_2i2+MZe2j6xgpP4Rs5mnupw@mail.gmail.com> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com> <EE6304FA8F854718909CE5544B3F4D50@WeiGengyuPC>
Date: Tue, 27 Jun 2017 16:21:55 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: weigengyu <weigengyu@vip.sina.com>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, lp-wan@ietf.org, arun@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, 27 Jun 2017 16:22:28 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/1ecqCVSfdQcAlmAPEo7iJd-hoIQ>
Subject: Re: [lp-wan] Fw: 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, 27 Jun 2017 14:22:41 -0000

Hi Gengyu,

Thanks for your proposal, I see you are trying to reduce header overhead.
However, I'm afraid there are still issues with it.

In the context of the SCHC specification, an L2 LPWAN frame may carry an
unfragmented IPv6 datagram with a compressed header (see Fig. 4). The Rule
ID is the first field of the compressed IPv6 datagram.

When a compressed IPv6 datagram needs to be fragmented, then some Rule ID
space (of size R bits) is 'stolen' and used for fragmentation
functionality. So a requirement here is that whatever is defined for
fragmentation needs to be consistent with the format used for header
compression. Some special Rule ID (or set of Rule IDs in terms of R-bit
patterns) needs to be used to signal that a data unit being carried is a
fragment.

Note that we cannot risk communication failure due to e.g. loss of a first
fragment (which in your proposal carries a Rule ID) followed by other
fragments (which in your proposal do not carry a Rule ID) that are
actually received. In such case, a receiver may process the received data
units as e.g. unfragmented (compressed) IPv6 datagrams.

Cheers,

Carles



> Hi Pascal,
>
>> We need the Rule to say fragment on each fragment,
> All framents of a IPv6 packet obey one rule, the Rule ID is included in
> the
> first fragment is enough for conveying this information.
>
>> and then the dtag.
> All framents of the packet contain the same Dtag as defined.
>
>> Starting the next fragment with the dtag would confuse the parser which
>> would interpret the dtag as another rule.
> Put the Dtag at the front.
> Defining the first two bits of Dtag as an indication of the first
> fragment,
> fragments of the minddle and  the last fragment.
>
> 00 the first fragment
> 10 fragments of the minddle
> 11 the last fragment
>
> If the first two bits are '00', the Rule ID is followed.
> If the first two bits are not '00', the fragment does not contain the Rule
> ID.
> If the first two bits are 11, it is the last fragment.
>
> I believe that it is worth to have this two bit to suppress the space of
> Rule ID in the successive fragments.
>
> Regards,
>
> Gengyu WEI
> Network Technology Center
> School of Computer
> Beijing University of Posts and Telecommunications