On Tue, Aug 2, 2016 at 8:31 PM, Xavier Vilajosana < [email protected]> wrote:
> Hi Jiliang, > > inline again :) > > 2016-08-02 13:58 GMT+02:00 Jiliang Wang <[email protected]>: > >> 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? >> > > 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 > Then why node A should request 3 times? Should node B respond with all those cells in 3 packets after receiving one request? This makes the operation easier and more clear. Semantically, this means that A should not care about how many times should request to return all 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. >> > > 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? > This may depends on the normal upper layer operations. Is satisfying partial requests the common case? > > >>> 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
