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

Qin Wang <qinwang6top@yahoo.com> Wed, 07 September 2016 20:28 UTC

Return-Path: <qinwang6top@yahoo.com>
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 7528F12B251 for <6tisch@ietfa.amsl.com>; Wed, 7 Sep 2016 13:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 7AunuW4gtmte for <6tisch@ietfa.amsl.com>; Wed, 7 Sep 2016 13:28:13 -0700 (PDT)
Received: from nm44-vm7.bullet.mail.bf1.yahoo.com (nm44-vm7.bullet.mail.bf1.yahoo.com [216.109.115.31]) (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 B134F12B234 for <6tisch@ietf.org>; Wed, 7 Sep 2016 13:28:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1473280091; bh=qlQJCLFL8vh+MGmAgeFwcvrvGs8/5qfPsPG7LaGMPfE=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=O2j6K84s4AKz6rpWNXx3HnV4t4YaFZK3g5Gt9kOl9yOKfqYkc+IdbRq7wfV1ANa3X8r+9R2IY+Gm26bwP7QNIoKZLv/VHjgg6MCdS6s7PM5+515SnE2qtjWjar+ZMQ5DuurOIqzt8HjVulQocc8mJaCBnNKUwE7WpKwtAe3aNexTiN2Qos+iMXWvTnhr+0g3/LQfy32tfqlaEg6RtKC/zgBNsZaz5KkD6BRhzz5fV0cPj3MutyNAEiN2vpKBjwwddKThI5WJw7WCg3/8fh463fKcz4bQKYlY3XugFDuRgVSGMN93LmYWw+1Z7ea2PdN3tvFtN+HZsf4+2zAR6j9Imw==
Received: from [98.139.215.142] by nm44.bullet.mail.bf1.yahoo.com with NNFMP; 07 Sep 2016 20:28:11 -0000
Received: from [98.139.212.195] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 07 Sep 2016 20:28:11 -0000
Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 07 Sep 2016 20:28:11 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 738063.1560.bm@omp1004.mail.bf1.yahoo.com
X-YMail-OSG: uDU6yQ0VM1kukT9Sy72L3AYVo_wAjxoAt5XMhG0yAsh3EA8BHhDfsK83W_t18bo wb8IrWPgnzJaPKXqInomOY9jctHhAV3o21AbfqPMB8nLFipbFfxHkqjaMDaOhqMtozZGDf_h0BNC OdPGO_k09NjDigu3wVB7PeiFdT46zFjzI_q3kiBL97m5Mcfd_xKht7wqRmqxHnRH..t7wF8KnGS4 UU8ZzCHUvxpzad7AZrDy4cQxm16pC9QF_GFv9Jqqd6AyHE0KKglE8YQyhSKzsgeO3Nmar3ADDrSD 6K_JQLqCq1UA6WjhiVRCts0Sx3.Sm5Weffk_NuTIzclU.Wo3aS1kvf0cf7zpQ.alvLiXmAcpxofw Mkwf28P035oRBNIec_i3PUM.BLdEHshOrw2h3mZGEnlhglPwRrrCXMOoocEklffBBRfaqKJjQUu5 PDC72lsXmldRMpe6uHGikIGZ0HIl9kD1nec6kXFACCs_Uw0tRXy.fDaUohRxrRzmgP4WADDEsh3k VX5X8MGETn0Cw2ty33fOciV0GBHAKgpSqFvlEBCk-
Received: from jws106189.mail.bf1.yahoo.com by sendmailws102.mail.bf1.yahoo.com; Wed, 07 Sep 2016 20:28:11 +0000; 1473280091.338
Date: Wed, 07 Sep 2016 20:26:37 +0000
From: Qin Wang <qinwang6top@yahoo.com>
To: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>, "6tisch@ietf.org" <6tisch@ietf.org>
Message-ID: <1150875178.1281140.1473279997957@mail.yahoo.com>
In-Reply-To: <CAMsDxWTSj3Yyu8wo5=p52DBycLS9pKAO263on24=z+R-FsTqDg@mail.gmail.com>
References: <CAMsDxWTSj3Yyu8wo5=p52DBycLS9pKAO263on24=z+R-FsTqDg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1281139_703853973.1473279997949"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/hUD5rKHzyaUtuAQquk1nVf0vAq8>
Subject: Re: [6tisch] follow up LIST cmd 6P
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Qin Wang <qinwang6top@yahoo.com>
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: Wed, 07 Sep 2016 20:28:14 -0000

Hi Xavi,
I think there are two scenarios which may result in the number of cells in the CellList of response packet less than numCells_max, (1)  when node B has N cells, where Offset<N and N<Offset+numCells_max cells; (2) when node B has more than Offset+numCells_max cells, but numCells_max cells cannot be fitted in the packet.
My question is how to distinguish one from another from node A side? Did I miss something?
ThanksQin 

    On Tuesday, September 6, 2016 4:45 AM, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:
 

 Hi,
according to our discussion during the last 6TiSCH meeting I want to follow up Tero's proposal for the LIST cmd.
here you will find his initial proposalhttps://www.ietf.org/mail-archive/web/6tisch/current/msg04719.html
As a summary, the proposal enables 6P list to return a best effort set of cells, this is as many as can be fitted in a packet below a maximum. This makes the list command robust to the presence of other IEs in the packet (which sometimes may be present and some times don't and hence would make two identical requests to succeed or fail. With this approach LIST is independent of the remaining space in the packet)

I follow up the discussion by proposing these changes to 6P.
1- change numCells field to numCells_max as follow:
                        1                   2      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |Version|  Code |    SFID       | SeqNum|GAB|GBA|   Metadata     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Metadata    |            Offset             |   numCells_max     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     |     +-+-+-+-+-+-+-+-+
where 
numCells_max:  The maximum number of requested cells.  Less cells         than numCells_max can be returned if they do not fit in the         packet.
Then I propose the following text
4.3.10.  Listing Cells
   When a node A issues a LIST_AB or LIST_BA command, it specifies:
   o  Through the "Offset" field, the offset of the first cell to be      present in the returned list.  The cell ordering policy is defined      by the SF.   o  Through the "numCells_max" field, the maximum number of cells to      be present in the reponse.  If numCells_max cannot be fitted in the      packet less cells will be returned.
   When receiving a LIST_AB command, node B returns the cells that are   scheduled from A to B in its schedule (i.e. receive cells from node   A).  When receiving a LIST_BA command, node B returns the cells that   are scheduled from B to A in its schedule (i.e. transmit cells to   node A).  The RECOMMENDED format of each 6P Cell is defined in   Section 4.2.5.  The SF MAY redefine the format of the CellList field.
   Depending on how many cells node B has in its schedule which match the   LIST_AB or LIST_BA request, the cellList returned in the 6P Response   contains between 0 and numCells_max cells:
   o  If node B has more than Offset+numCells cells, the cellList it      returns contains exactly numCells cells as long as the cellList      fits in the packet.  Otherwise it returns a cellList containing      the maximum number of cells that fit in the packet.   o  If node B has N cells, where Offset<N and N<Offset+numCells_max      cells, the cellList it returns contains exactly N-Offset cells.      If that number of cells do not fit in the packet, the cellList      containing the maximum number of cells that fit in the packet is      returned.   o  If node B has less than Offset cells, the cellList it returns is      empty.

Please, raise any pros and cons you may find in this approach.
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch