Re: [lp-wan] I-D Action: draft-ietf-lpwan-architecture-02.txt

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Mon, 04 July 2022 16: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 CFCC0C15AD43; Mon, 4 Jul 2022 09:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.926
X-Spam-Level:
X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXnzcvIhzCsB; Mon, 4 Jul 2022 09:58:01 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 B6E9DC15AD2E; Mon, 4 Jul 2022 09:58:00 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.40.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 264GvrAU053496; Mon, 4 Jul 2022 18:57:53 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.40.6]) by entelserver.upc.edu (Postfix) with ESMTP id E8BAF1D53C1; Mon, 4 Jul 2022 18:56:48 +0200 (CEST)
Received: from 79.159.90.85 by webmail.entel.upc.edu with HTTP; Mon, 4 Jul 2022 18:57:53 +0200
Message-ID: <2617a997c529fa3a79bb8e12f0adf7f2.squirrel@webmail.entel.upc.edu>
In-Reply-To: <165660921915.27630.13288754785651669910@ietfa.amsl.com>
References: <165660921915.27630.13288754785651669910@ietfa.amsl.com>
Date: Mon, 04 Jul 2022 18:57:53 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: pthubert@cisco.com
Cc: 6lo@ietf.org, lp-wan@ietf.org
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.103.6 at dash
X-Virus-Status: Clean
X-Greylist: Delayed for 97:56:50 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Mon, 04 Jul 2022 18:57:53 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/mgBPBKthJh1KEuxXJEUzZ_ONABc>
Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-architecture-02.txt
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 04 Jul 2022 16:58:04 -0000

Hi Pascal,

(CC'ing 6lo.)

Many thanks for updating the LPWAN architecture draft as per our discussion!

In my opinion, the draft now provides the basis to generalize the use of
the SCHC roles (Dev and App) or directions (Downlink and Uplink) for any
networking environment or topology.

(And other drafts, such as draft-gomez-6lo-schc-15dot4, can now refer to
the LPWAN architecture draft to this end.)

I have two further comments:

- In section 5.1, when talking about the P2P SCHC Instance, an assumption
seems to be that there is one link between the two peers. However, there
could be several links (understood as radio hops) between the peers. For
the sake of generality, perhaps the draft could also explicitly mention
that there can be a link **or a path** between the two peers, perhaps also
explicitly referring to 'mesh' or 'multihop' networks, which are now
covered by the draft as well.

- The convention defined in 5.1 provides a default way to determine who is
Dev and who is App (or what is understood by Uplink and Downlink).
My interpretation is that:

   o If it is possible to know beforehand which one of the two peers is Dev
     or App, a single Rule (also written beforehand) may suffice to offer
     the best header compression performance for both communication
     directions (e.g., as in RFC 8724).

   o In a less predictable scenario, where either one peer or the other
     could be the first to transmit (e.g., if they are peers in a strict
     sense), the convention still allows to determine the role of each
     device, but two Rules (one for each direction) may need to be written
     to achieve the best header compression performance for both
     communication directions (one for each direction).

  Perhaps some comment about this (i.e., the amount of context may be
  reduced if a scenario is predictable) could also be added to the draft.

Cheers,

Carles


> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over Low Power Wide-Area Networks WG
> of the IETF.
>
>         Title           : LPWAN Static Context Header Compression (SCHC)
> Architecture
>         Authors         : Alexander Pelov
>                           Pascal Thubert
>                           Ana Minaburo
>   Filename        : draft-ietf-lpwan-architecture-02.txt
>   Pages           : 14
>   Date            : 2022-06-30
>
> Abstract:
>    This document defines the LPWAN SCHC architecture.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lpwan-architecture/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-architecture-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-architecture-02