Re: [6tisch] follow up LIST cmd 6P

Thomas Watteyne <thomas.watteyne@inria.fr> Fri, 09 September 2016 20:22 UTC

Return-Path: <thomas.watteyne@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F7F12B1CE for <6tisch@ietfa.amsl.com>; Fri, 9 Sep 2016 13:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.406
X-Spam-Level:
X-Spam-Status: No, score=-8.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.001, RP_MATCHES_RCVD=-1.508] 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 EVovux7oHbZv for <6tisch@ietfa.amsl.com>; Fri, 9 Sep 2016 13:22:19 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817DC12B027 for <6tisch@ietf.org>; Fri, 9 Sep 2016 13:22:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.30,306,1470693600"; d="scan'208,217";a="235912996"
Received: from mail-wm0-f44.google.com ([74.125.82.44]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 09 Sep 2016 22:22:08 +0200
Received: by mail-wm0-f44.google.com with SMTP id w12so49818122wmf.0 for <6tisch@ietf.org>; Fri, 09 Sep 2016 13:22:08 -0700 (PDT)
X-Gm-Message-State: AE9vXwOFQ85SBKCXGJRRciZ/+NXkQvlaAf/IJjIQnFr4MBu/ROmsnJD9ORioMIKYEkz7Z/fFEEPPdSbfP/8hgg==
X-Received: by 10.195.12.4 with SMTP id em4mr4822855wjd.32.1473452528304; Fri, 09 Sep 2016 13:22:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.173.135 with HTTP; Fri, 9 Sep 2016 13:21:47 -0700 (PDT)
In-Reply-To: <22481.24001.374385.655166@fireball.acr.fi>
References: <CAMsDxWTSj3Yyu8wo5=p52DBycLS9pKAO263on24=z+R-FsTqDg@mail.gmail.com> <1150875178.1281140.1473279997957@mail.yahoo.com> <CADJ9OA9su_FEfz8YHicJNCG1DCM6TGVvo2pQSKOT7CL+OnPsFA@mail.gmail.com> <22481.20577.467824.725921@fireball.acr.fi> <CADJ9OA83s1=quZWMDAjcvGKXXWtkyki8BUg8UECfWEut7x7RvA@mail.gmail.com> <22481.24001.374385.655166@fireball.acr.fi>
From: Thomas Watteyne <thomas.watteyne@inria.fr>
Date: Fri, 09 Sep 2016 22:21:47 +0200
X-Gmail-Original-Message-ID: <CADJ9OA-aZhnBP3Wi-+3h1hsprU=44txZ75Uxk6x2OTsUxp6yxw@mail.gmail.com>
Message-ID: <CADJ9OA-aZhnBP3Wi-+3h1hsprU=44txZ75Uxk6x2OTsUxp6yxw@mail.gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
Content-Type: multipart/alternative; boundary="047d7bfd029e8b0f26053c18e686"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/cxn9JZOc_3p4ZaEPd6uZPJPPHH4>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
Subject: Re: [6tisch] follow up LIST cmd 6P
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2016 20:22:21 -0000

Tero,

Thanks for the explanation.

I looks like a single sentence in the 6P draft banning piggybacking
non-6P IEs would make the problem disappear, no?

Thomas

On Thu, Sep 8, 2016 at 2:46 PM, Tero Kivinen <kivinen@iki.fi> wrote:

> Thomas Watteyne writes:
> > I agree no functionality is lost if the mote must return at least one
> cell.
> > But it's a race condition: what happens if there are so many other IEs
> that
> > there is no space at all, even for a single cell.
>
> If we have that many other IEs, then we do have other issues too. I
> mean, the examples we have given are using really tiny frames,
> something like 30 octets. The default frame size is 127, so I do not
> really expect it to lower the number of cells down to 4, but closer to
> 20...
>
> > And while I am not doubting that many more IEs will be invented for many
> > different things, I'm skeptical when you explain that all of these will
> > happily be piggybacked in 6P messages. Surely there must be a sentence in
> > 15.4-2015 that explains the rules for piggybacking?
>
> Nope. All of that is left for upper layers to decide. IEEE
> specifications just define the IEs, and how they are encoded, and in
> latest version it also includes in which frame types they are
> typically used, but when to send them is mostly left for
> implementations to decide.
>
> In some cases it do say that certain IEs shall be piggybacked, like
> Time Correction IE and Link Margin IE (from 802.15.4q). Those both are
> in Enhanced ACKs so they are not an issue here, but for example the
> 802.15.10 (mesh networking) will put some routing etc IEs on all
> frames. Fortunately it is most likely not used with 6tisch.
>
> Anyways mostly this is just in case someone adds more and more IEs
> that do things on frames. Currently there is not that many that are
> added in the data frames, or at least there is no defined use for
> them...
>
> This issue is much bigger on the Enhanced Beacons, as there is so many
> different IEs you can put there.
> --
> kivinen@iki.fi
>



-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________