Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6top-protocol-02.txt
Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> Tue, 02 August 2016 12:31 UTC
Return-Path: <xvilajosana@gmail.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 1DE5312D591 for <6tisch@ietfa.amsl.com>; Tue, 2 Aug 2016 05:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CKTfSjMvpriF for <6tisch@ietfa.amsl.com>; Tue, 2 Aug 2016 05:31:38 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 EE4CB12D580 for <6tisch@ietf.org>; Tue, 2 Aug 2016 05:31:36 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id l69so137114398lfg.1 for <6tisch@ietf.org>; Tue, 02 Aug 2016 05:31:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4jemIk2898HVrxqgDwx7T5TeYR/4wEyqVwieRqWoPNY=; b=jZXz7MBchmqsbRvfLVMGBh2aM4vmonXOiHwavvHYOZiXM7pOLg3OGcU11DvTAux/H4 W74e0CsI71Ge8fiOlQiwHQKHHoy0OkbapaGeVFLkjf2tMStqO160Jk0MYvDmWd7ujurN nKQObh3aXGKVlJck/idGcsi2qKpfJ5iQAZUxKipLq89TbfpMUNfYm+CyxVU+JNtMJf8Z wR/QCwe2satCKkizOgLn2ycwomiZjKM0pkAChEqSfrTnTfA/ThzbZpC59EqB2DB8yEQ1 3x/PRwkMh+YiWGZrq8gel+Jj50YYTSIhVLDzWxM7vpQbuWFJZTyb2kjoyhLNCq26ye9/ xOAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4jemIk2898HVrxqgDwx7T5TeYR/4wEyqVwieRqWoPNY=; b=B8ILsyJKNxPoq21eJHFKtCgt+SoZ0TngAdSQTtvjRR8CLeWddt/87eMh6r8dCob/Xz dicPL36d6qGygBB6gYuda8LLA3EvYgJfAoq1eDngQxMVGkB3G/DYMr6Ftd32kpEebn0J ZDpLCdSS5IKWxgrmNQLVBlaHLidSAtetdIeDMBZ7jONHD0OfCSDyY9JOegtM6PzRtk+n LHcF0kLiSN6GVHSTOlsL7+NTDbtV9bzSDo04NIWHAhStKyD/3f0WkJ6g2Y63SSEDeFHe tvZtnhShfYTy92YtRohc+0uXphY2DWWZNXAbIBlwR1osfRm/G5ch3Pfg0FEUfREpQcl3 0HpA==
X-Gm-Message-State: AEkoouuU0ab1OYU/dGq6KLrVaN34AETPDVRv6IbOb2WrcHsgbsxdHDLaPZmBTAITtWF7bcnZlZrR3qpHPEhYAg==
X-Received: by 10.25.1.133 with SMTP id 127mr22257988lfb.54.1470141094900; Tue, 02 Aug 2016 05:31:34 -0700 (PDT)
MIME-Version: 1.0
Sender: xvilajosana@gmail.com
Received: by 10.25.1.196 with HTTP; Tue, 2 Aug 2016 05:31:33 -0700 (PDT)
In-Reply-To: <CAC=zv2NZbJBrFjFpdmFJVgrRT6okzCHoxRXrdCnNOM7XezakiA@mail.gmail.com>
References: <20160726063035.11416.82424.idtracker@ietfa.amsl.com> <CAMsDxWRQ1+zbhuCypNS2aHsTtXCtu+MnMu6ig89vLrk2_FxaEg@mail.gmail.com> <1283033447.423092.1469520332086.JavaMail.root@llavaneres.uoc.es> <CAC9+vPjqLfs4xoq3mkDMp9pxnc24iMPT31+1WYwuG_zSNQzVgA@mail.gmail.com> <CAC=zv2M1DXZTa-siHieOpbjdCEqwz=+bRt-gmSFm_qYZ_MZ=8g@mail.gmail.com> <CAMsDxWT12L4bdX2_WQ04vdt5B4g4Vk2zY7gULw+10Kgm28=Abg@mail.gmail.com> <CAC=zv2NZbJBrFjFpdmFJVgrRT6okzCHoxRXrdCnNOM7XezakiA@mail.gmail.com>
From: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
Date: Tue, 02 Aug 2016 14:31:33 +0200
X-Google-Sender-Auth: _7ZNMj2xr4hUcZyc1xhEvTeskGU
Message-ID: <CAMsDxWTHvGxNusaqs8JNLy_9nej4VyTSHKi+-zps=Eg7AxTCtw@mail.gmail.com>
To: Jiliang Wang <jiliangwang99@gmail.com>
Content-Type: multipart/alternative; boundary="001a113b0220bb388b053915e515"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/5d1esIpSTygEW_i6jNWeChRWLOg>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Xavi Vilajosana Guillén <xvilajosana@uoc.edu>
Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6top-protocol-02.txt
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: Tue, 02 Aug 2016 12:31:41 -0000
Hi Jiliang, inline again :) 2016-08-02 13:58 GMT+02:00 Jiliang Wang <jiliangwang99@gmail.com>: > Thanks. please see inline my comments. > > On Tue, Aug 2, 2016 at 7:29 PM, Xavier Vilajosana < > xvilajosana@eecs.berkeley.edu> wrote: > >> Hi Jiliang, >> >> see inline please, >> >> 2016-07-29 15:33 GMT+02:00 Jiliang Wang <jiliangwang99@gmail.com>: >> >>> Thanks very much for your response. My comments are as follows. >>> >>> On Tue, Jul 26, 2016 at 9:14 PM, Xavi Vilajosana Guillén < >>> xvilajosana@uoc.edu> wrote: >>> >>>> Dear Jiliang, >>>> >>>> see inline please, >>>> >>>> 2016-07-26 10:05 GMT+02:00 Jiliang Wang <jiliangwang99@gmail.com>: >>>> >>>>> Thanks for the great work. This is Jiliang Wang from Tsinghua >>>>> University. I am very interested in this version and I just have several >>>>> questions. >>>>> >>>>> 1. In 4.3.10, it says “If node A requests more cells than can >>>>> fit in the response, node B MUST return code RC_ERR_NORES and an empty cell >>>>> list.” >>>>> >>>>> 1.- Is there any fragmentation method to transmit all the cells if >>>>> the requested cells cannot be fit in a response? >>>>> >>>> No, we keep it simple. The LIST command supports pagination. You can >>>> retry with a smaller page size if it does not fit in a packet. >>>> >>> Is the pagination decision made by node A? This seems to be not simple >>> since the actual number is not know and thus it is difficult to determine >>> whether to use pagination. >>> >> >> A node knows the bytes it can fit in a packet. This gives an indication >> to the node of what is the number of items that can be requested. When a >> node issues a LIST it starts by offset 0, this returns the first N >> scheduled cells. Then it seems reasonable that the node will indicate >> offset N and request N more cells ... >> If the number of requested cells does not fit in the packet an error is >> returned and the node retries again with a smaller value of N. >> I do not see a big complexity on that. What issues do you see? >> > Then how to deal with the case that a node has cells more than that can be > fitted in a packet. Is there any method to return all those cells? > that is why we use pagination. Assume the command LIST_AB issued by node A to node B. Assume B has 10 cells in its schedule being (1,3,5,7,9,11,13,15,17,19), assume also that a packet can only transport 4 cells. Node A can issue STATUS to Node B. B will respond ti has 10 cells. then Node A will issue LIST_AB offset=0 num cells=4 Node B will respond 1,3,5,7 Node A then will issue LIST_AB offset=4 num cells=4 Node B will respond 9,11,13,15 Node A then will issue LIST_AB offset=8 num cells=2 Node B will respond 17,19 2. Will the clear command result in inconsistency in current design? >>>>> For example, a clear command is sent from A to B and the response from B to >>>>> A is lost. >>>>> >>>> The CLEAR is not executed until the response is received. B side >>>> executes the CLEAR after receiving the L2 ACK of the response message. >>>> >>> It there any problem when the L2 ACK is lost in which A clears while B >>> does not? >>> >> >> In a TSCH network the probability of losing the ACK is very low. As the >> packet has already been sent the ACK has extremely high chances to pass as >> well (it is shorter in length which still favours the transmission >> success). Of course this can remotely happen and if this happens the system >> should recover from that inconsistency. To do so the generation counters >> will enable the detection of the inconsistency and both nodes schedule will >> be cleared (only cells between them). >> The alternative is to use a 3 step transaction, which requires 33% more >> packets over the air at every transaction. We decided to avoid that. Maybe >> a research question is to evaluate in a real deployment the energy overhead >> of using 3 way transactions vs eventually recovering from a lost ACK during >> a CLEAR. Given the chances of losing an ACK I would bet for the later. >> > Yes, agree. I also agree that the probability should be low and 3-way > handshaking may be overwhelming in this case. As long as clear can be used > to deal with the inconsistency (with low probability), the protocol should > be ok. > >> :) > >> > 3. Currently, the add command supports best-effort cell adding, >>>>> i.e., when the cells is not enough, partial of the cells can be added – if >>>>> I understand correctly. >>>>> >>>>> –what is the purpose of best-effort adding. Why not just return >>>>> success and fail? >>>>> >>>> Best effort minimizes the amount of data to be sent. >>>> >>> Is it possible that a node needs to issue an all-or-no adding request? >>> For example, a node prefers to transmit all data at once. >>> >> I would separate the data plane from the control plane. For me ADD is an >> operation that deals with the reservation of cells (control plane). If ADD >> does not meet the requirements in a particular moment in time, the SF will >> take care of requesting other cells. If this introduces a delay between >> when the cells are requested and when all of the requested cells can be >> used is something we need to evaluate. There is always the option that the >> application requesting the bw blocks until all cells have been allocated. >> This is out of the scope in 6top. >> > My question is that A node may want to allocate, say 6 cells, B node > should return 0 or 6 instead of any other number in between. Otherwise, the > upper layer scheduler SF cannot schedule the communication in a fine > granularity. For example, SF may realized 6 cannot be satisfied and it may > decide to wait instead of using partial of the cells. > I see. I wonder if this case is something we should worry. Usually the schedules are sparse in these networks. If this eventually happen maybe we can tolerate the SF to delete the cells and wait. What alternative would you propose? and what would be the benefit vs overhead/drawback vs a best-effort approach in the most common cases? >> kind regards, >> Xavi >> >>> >>>> >>>> >>>>> best, >>>>> >>>>> >>>> Kind regards, >>>> Xavi >>>> >>>>> ------------- >>>>> Jiliang Wang >>>>> Assistant Professor >>>>> http://tns.thss.tsinghua.edu.cn/~jiliang/ >>>>> >>>>> On Tue, Jul 26, 2016 at 2:32 PM, Xavier Vilajosana < >>>>> xvilajosana@eecs.berkeley.edu> wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> we have submitted a revision of the 6top draft. It includes most of >>>>>> the changes proposed in the WG meeting in Berlin. >>>>>> >>>>>> please send us your comments. >>>>>> >>>>>> kind regards, >>>>>> Xavi >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: <internet-drafts@ietf.org> >>>>>> Date: 2016-07-26 8:30 GMT+02:00 >>>>>> Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-protocol-02.txt >>>>>> To: i-d-announce@ietf.org >>>>>> Cc: 6tisch@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the IPv6 over the TSCH mode of IEEE >>>>>> 802.15.4e of the IETF. >>>>>> >>>>>> Title : 6top Protocol (6P) >>>>>> Authors : Qin Wang >>>>>> Xavier Vilajosana >>>>>> Filename : draft-ietf-6tisch-6top-protocol-02.txt >>>>>> Pages : 28 >>>>>> Date : 2016-07-25 >>>>>> >>>>>> Abstract: >>>>>> This document defines the 6top Protocol (6P), which enables >>>>>> distributed scheduling in 6TiSCH networks. 6P allows neighbor >>>>>> nodes >>>>>> in a 6TiSCH network to add/delete TSCH cells to one another. 6P is >>>>>> part of the 6TiSCH Operation Sublayer (6top), the next higher layer >>>>>> of the IEEE802.15.4 TSCH medium access control layer. The 6top >>>>>> Scheduling Function (SF) decides when to add/delete cells, and >>>>>> triggers 6P Transactions. Several SFs can be defined, each >>>>>> identified by a different 6top Scheduling Function Identifier >>>>>> (SFID). >>>>>> This document lists the requirements for an SF, but leaves the >>>>>> definition of the SF out of scope. Different SFs are expected to >>>>>> be >>>>>> defined in future companion specifications. >>>>>> >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-protocol-02 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> 6tisch mailing list >>>>>> 6tisch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 6tisch mailing list >>>>>> 6tisch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 6tisch mailing list >>>>> 6tisch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dr. Xavier Vilajosana Guillén >>>> Research Professor >>>> Wireless Networks Research Group >>>> Internet Interdisciplinary Institute (IN3) >>>> Universitat Oberta de Catalunya >>>> >>>> +34 646 633 681| xvilajosana@uoc.edu | Skype: xvilajosana >>>> http://xvilajosana.org >>>> http://wine.rdi.uoc.edu/ >>>> >>>> Parc Mediterrani de la Tecnologia >>>> Av. Carl Friedrich Gauss, 5. Edifici B3 >>>> 08860 Castelldefels (Barcelona) >>>> >>>> >>>> >>>> >>>> >>> >>> >> >
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Xavi Vilajosana Guillén
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Tero Kivinen
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Xavier Vilajosana
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Xavier Vilajosana
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Jiliang Wang
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Tero Kivinen
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Tero Kivinen
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Jiliang Wang
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Xavier Vilajosana
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Xavier Vilajosana
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Jiliang Wang
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Lijo Thomas
- Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6… Jiliang Wang
- [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6top-… Xavier Vilajosana
- [6tisch] I-D Action: draft-ietf-6tisch-6top-proto… internet-drafts