Thanks. please see inline my comments. On Tue, Aug 2, 2016 at 7:29 PM, Xavier Vilajosana < [email protected]> wrote:
> Hi Jiliang, > > see inline please, > > 2016-07-29 15:33 GMT+02:00 Jiliang Wang <[email protected]>: > >> Thanks very much for your response. My comments are as follows. >> >> On Tue, Jul 26, 2016 at 9:14 PM, Xavi Vilajosana Guillén < >> [email protected]> wrote: >> >>> Dear Jiliang, >>> >>> see inline please, >>> >>> 2016-07-26 10:05 GMT+02:00 Jiliang Wang <[email protected]>: >>> >>>> 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? > 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. > > 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 < >>>> [email protected]> 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: <[email protected]> >>>>> Date: 2016-07-26 8:30 GMT+02:00 >>>>> Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-protocol-02.txt >>>>> To: [email protected] >>>>> Cc: [email protected] >>>>> >>>>> >>>>> >>>>> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>>> >>>>> _______________________________________________ >>>>> 6tisch mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> 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| [email protected] | 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) >>> >>> >>> >>> >>> >> >> >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
