Re: [6tisch] follow up LIST cmd 6P
Thomas Watteyne <thomas.watteyne@inria.fr> Thu, 08 September 2016 12:06 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 0B54212B173 for <6tisch@ietfa.amsl.com>; Thu, 8 Sep 2016 05:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level:
X-Spam-Status: No, score=-8.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 GlTPQjXbXim6 for <6tisch@ietfa.amsl.com>; Thu, 8 Sep 2016 05:06:18 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 4487212B2D9 for <6tisch@ietf.org>; Thu, 8 Sep 2016 04:58:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.30,300,1470693600"; d="scan'208,217";a="192487997"
Received: from mail-wm0-f52.google.com ([74.125.82.52]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 08 Sep 2016 13:58:32 +0200
Received: by mail-wm0-f52.google.com with SMTP id b187so164433567wme.1 for <6tisch@ietf.org>; Thu, 08 Sep 2016 04:58:32 -0700 (PDT)
X-Gm-Message-State: AE9vXwPD0sZMq+AQsTyNgVSqcrIKyW3x8uB9IGn80TNZtwWNI61TpMIc7+jsWzAze9NeN//6Y/plZyn5YjcDqg==
X-Received: by 10.28.41.6 with SMTP id p6mr8452036wmp.18.1473335912275; Thu, 08 Sep 2016 04:58:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.173.135 with HTTP; Thu, 8 Sep 2016 04:58:31 -0700 (PDT)
In-Reply-To: <22481.20577.467824.725921@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>
From: Thomas Watteyne <thomas.watteyne@inria.fr>
Date: Thu, 08 Sep 2016 13:58:31 +0200
X-Gmail-Original-Message-ID: <CADJ9OA83s1=quZWMDAjcvGKXXWtkyki8BUg8UECfWEut7x7RvA@mail.gmail.com>
Message-ID: <CADJ9OA83s1=quZWMDAjcvGKXXWtkyki8BUg8UECfWEut7x7RvA@mail.gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
Content-Type: multipart/alternative; boundary="001a114e32eaafd0ad053bfdbf85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/K5fBYgOSutATqQE6ElZJd8-02PA>
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: Thu, 08 Sep 2016 12:06:23 -0000
Tero, 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. 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? Thomas On Thursday, September 8, 2016, Tero Kivinen <kivinen@iki.fi> wrote: > Thomas Watteyne writes: > > Same question here. > > And frankly I fail to understand what the problem is we are trying to > fix. > > In today's text: > > - if I receive less cells than I asked for, that means "end of list". > > You get information how many cells there are by doing status request > first. I.e. you do STATUS request and get STATUS response back saying > there 10 cells from A to B, and 5 to B to A. > > Then you do LIST_AB request with offset = 0, numCells = 4. Now, the > other end is supposed to send you exaclty first 4 cells. If it cannot > then it returns error. The issue with error is that forces the other > end to remake the request with smaller number of numCells, and if this > was just caused by some IE to be added to response this will create > extra traffic. With new approach it will just return 3 cells, and > there is no wasted frames because of someone added IEs to response. > > Also you do not need to do STATUS command even in this scenario, as > if you ask cells starting from offset, which is bigger than the number > of cells, you get empty list, which will signal that there is no more > cells. I think we need to define that in other cases you need to > return at least one cell, i.e., only case where you are allowed to > send zero cells is when you are end of list. > > So currently the process works like this: > > Node A Node B > STATUS -> > <- A->B 10, B->A 5 > LIST_AB o=0,nc=4 -> > <- 4 cells > LIST_AB o=4,nc=4 -> > <- responder cannot return 4 cells, as > there is other stuff to be returned > too, it returns error > RC_ERR_NORES (no cells) > LIST_AB o=4,nc=3 -> > sender lowers nc <- responder still cannot return that > many cells, and returns error again > RC_ERR_NORES (no cells) > LIST_AB o=4,nc=2 -> > sender lower nc again <- 2 cells (+ other stuff making > frame big) > LIST_AB o=6,nc=2 -> > sender keeps low nc <- 2 cells (and no other stuff, so > could have returned 4 cells) > LIST_AB o=8,nc=2 -> > <- 2 cells > As A did STATUS he now > knows he have everything. > If he did not do the STATUS > he will do next request > LIST_AB o=10,nc=2 -> > <- 0 cells indicating end of list. > > Of course the Node A could also raise nc back to 4 when it gets the > reply back, but that would cause it to send more frames in those cases > where there is always some extra stuff in frame. > > With new proposed version: > > > Node A Node B > STATUS -> > <- A->B 10, B->A 5 > LIST_AB o=0,nc=4 -> > <- 4 cells > LIST_AB o=4,nc=4 -> > <- responder cannot return 4 cells, as > there is other stuff to be returned > too, it returns only 2 > 2 cells (+ other stuff) > LIST_AB o=6,nc=4 -> > <- 4 cells (there is no other stuff > to send, so can fit 4) > LIST_AB o=10,nc=4 -> > <- 0 cells indicating end of list. > > Of course if the Node A did the STATUS request, he could leave the > last request out, as he knows he already have everything as there is > only 10 cells. > > > - if I ask for more cells that fit in the packet, I receive a "no > resources" > > error. I can then try again, asking for a smaller number of cells > > That seams to work, no? > > So what is the problem we are trying to solve again? > > With more and more features in 802.15.4 there will most likely be > other management kind of IEs added to the frames. This will make it so > that maximum usable frame size changes over time depending what kind > of IEs are included to the frames. The new version is more flexible > with that, and should be easier to implement, as there is no need to > do fallbacks to smaller numCells requests etc. > -- > kivinen@iki.fi <javascript:;> > -- _______________________________________ 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 _______________________________________
- [6tisch] follow up LIST cmd 6P Xavier Vilajosana
- Re: [6tisch] follow up LIST cmd 6P Qin Wang
- Re: [6tisch] follow up LIST cmd 6P Thomas Watteyne
- Re: [6tisch] follow up LIST cmd 6P Xavier Vilajosana
- Re: [6tisch] follow up LIST cmd 6P Tero Kivinen
- Re: [6tisch] follow up LIST cmd 6P Thomas Watteyne
- Re: [6tisch] follow up LIST cmd 6P Tero Kivinen
- Re: [6tisch] follow up LIST cmd 6P Thomas Watteyne