Re: [6tisch] Comments on draft-chang-6tisch-msf-00
Hi Thomas, Xavi, > I would recommend to use a MAY in this case. That is, a node MUST remove > cells, and MAY send a CLEAR. That sounds good to me! Best, Yatch ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Comments on draft-chang-6tisch-msf-00
Yatch, About : *Why does the node have to issue a 6P CLEAR to a neighbor which is determined to be unreachable...? It just wastes time and energy of the initiator since this transaction will fail as the draft mentioned. I think it'd be fine to remove all the dedicated cells to the unreachable neighbor without 6P CLEAR. By the way, the term "cells" should be used instead of "links".* I would recommend to use a MAY in this case. That is, a node MUST remove cells, and MAY send a CLEAR. Thomas On Wed, Feb 14, 2018 at 5:28 AM, Xavi Vilajosana Guillen < xvilajos...@uoc.edu> wrote: > Dear Yatch, > > thanks for your comments! see inline my answers. > > 2018-02-13 18:13 GMT+01:00 Yasuyuki Tanaka : > >> Hi all, >> >> I'd like to share my comments on draft-chang-6tisch-msf-00: >> >>https://tools.ietf.org/html/draft-chang-6tisch-msf-00 >> >> The first one is about 6P CLEAR after detecting unreachability to a >> neighbor. >> >> > 3.8. Step 7 - Neighbor Polling >> > >> > (snip) >> > >> >When a neighbor is declared unreachable, the node MUST issue a 6P >> >CLEAR to that neighbor (which can fail at the link-layer), and MUST >> >remove all dedicated links with that neighbor from its own schedule. >> >> >> Why does the node have to issue a 6P CLEAR to a neighbor which is >> determined to be unreachable...? It just wastes time and energy of the >> initiator since this transaction will fail as the draft mentioned. I think >> it'd be fine to remove all the dedicated cells to the unreachable neighbor >> without 6P CLEAR. By the way, the term "cells" should be used instead of >> "links". >> >> > XV> I agree. A node can directly reset its schedule. We will change that > sentence. > > >> Other comments are trivial. >> >> > 1. Introduction >> > >> > (snip) >> > >> >MSF is designed to operate in a wide range of application domains. >> >It is optimized for applications with regular upstream traffic (from >> >the nodes to the Internet). >> >> "The internet" sounds too specific. "From the nodes toward the root" >> would be better? >> > > XV>> Agree. > >> >> > 2. Interface to the Minimal 6TiSCH Configuration >> > >> > (snip) >> > >> >MSF uses the minimal cell to exchange the following packets: >> > >> > ... >> > >> >4. The first 6P packet a node issues to a neighbor it doesn't have >> >dedicated cells to, as defined by >> >[I-D.ietf-6tisch-6top-protocol]. These are unicast frames. >> >> The minimal cell is used for not only the first 6P packet but also >> subsequent packets associated with a 6P transaction initiated by the first >> packet. In this sense, I'd like to propose to replace it with: >> >>6P packets to schedule the first dedicated cell with a neighbor. There >> are unicast frames. >> > > XV>> Agree. > >> >> > 7. Rules for CellList >> > >> > >> >MSF uses 2-step 6P Transactions exclusively. 6P Transactions are >> >only initiated by a node towards it preferred parent. As a result, >> >the cells to put in the CellList of a 6P ADD command, and in the >> >candidate CellList of a RELOCATE command, are chosen by the node. In >> >both cases, the same rules apply: >> > >> > the CellList SHOULD contain 5 or more cells. >> > Each cell in the CellList MUST have a different slotOffset value. >> > For each cell in the CellList, the node MUST NOT have any >> > scheduled cell on the same slotOffset. >> > The slotOffset value of any cell in the CellList MUST NOT be the >> > same as the slotOffset of the minimal cell (slotOffset=0). >> > The slotOffset of a cell in the CellList SHOULD be randomly and >> > uniformly chosen among all the slotOffset values that satisfy the >> > restriction above. >> > The channelOffset of a cell in the CellList SHOULD be randomly and >> > uniformly in [0..numFrequencies] where numFrequencies represents >> > the number of frequencies a node can communicate on. >> >> >> Is this a format error...? >> > > XV>> No, I think this is a bullet list with "invisible" bullets :) . We > add the bullets. > >> >> > 8. 6P Timeout Value >> > >> > >> >The 6P Timeout is not a constant value. It is calculated a (C/ >> >PDR)*6PTIMEOUT_SEC_FACTOR, where: >> >> >> I think it'd be better for a variable name to start with a non-numeric >> character even in a document. >> >> > XV>> Agree. > > >> That's it! >> >> Best, >> Yatch >> > > thanks Yatch! > regards > X > >> ___ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> > > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > > *Internet Interdisciplinary Institute (IN3)Professor* > (+34) 646 633 681 <+34%20646%2063%2036%2081> > xvilajos...@uoc.edu > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > 08860 Castelldefels (Barcelona). Catalonia. Spain > [im
Re: [6tisch] Comments on draft-chang-6tisch-msf-00
Dear Yatch, thanks for your comments! see inline my answers. 2018-02-13 18:13 GMT+01:00 Yasuyuki Tanaka : > Hi all, > > I'd like to share my comments on draft-chang-6tisch-msf-00: > >https://tools.ietf.org/html/draft-chang-6tisch-msf-00 > > The first one is about 6P CLEAR after detecting unreachability to a > neighbor. > > > 3.8. Step 7 - Neighbor Polling > > > > (snip) > > > >When a neighbor is declared unreachable, the node MUST issue a 6P > >CLEAR to that neighbor (which can fail at the link-layer), and MUST > >remove all dedicated links with that neighbor from its own schedule. > > > Why does the node have to issue a 6P CLEAR to a neighbor which is > determined to be unreachable...? It just wastes time and energy of the > initiator since this transaction will fail as the draft mentioned. I think > it'd be fine to remove all the dedicated cells to the unreachable neighbor > without 6P CLEAR. By the way, the term "cells" should be used instead of > "links". > > XV> I agree. A node can directly reset its schedule. We will change that sentence. > Other comments are trivial. > > > 1. Introduction > > > > (snip) > > > >MSF is designed to operate in a wide range of application domains. > >It is optimized for applications with regular upstream traffic (from > >the nodes to the Internet). > > "The internet" sounds too specific. "From the nodes toward the root" would > be better? > XV>> Agree. > > > 2. Interface to the Minimal 6TiSCH Configuration > > > > (snip) > > > >MSF uses the minimal cell to exchange the following packets: > > > > ... > > > >4. The first 6P packet a node issues to a neighbor it doesn't have > >dedicated cells to, as defined by > >[I-D.ietf-6tisch-6top-protocol]. These are unicast frames. > > The minimal cell is used for not only the first 6P packet but also > subsequent packets associated with a 6P transaction initiated by the first > packet. In this sense, I'd like to propose to replace it with: > >6P packets to schedule the first dedicated cell with a neighbor. There > are unicast frames. > XV>> Agree. > > > 7. Rules for CellList > > > > > >MSF uses 2-step 6P Transactions exclusively. 6P Transactions are > >only initiated by a node towards it preferred parent. As a result, > >the cells to put in the CellList of a 6P ADD command, and in the > >candidate CellList of a RELOCATE command, are chosen by the node. In > >both cases, the same rules apply: > > > > the CellList SHOULD contain 5 or more cells. > > Each cell in the CellList MUST have a different slotOffset value. > > For each cell in the CellList, the node MUST NOT have any > > scheduled cell on the same slotOffset. > > The slotOffset value of any cell in the CellList MUST NOT be the > > same as the slotOffset of the minimal cell (slotOffset=0). > > The slotOffset of a cell in the CellList SHOULD be randomly and > > uniformly chosen among all the slotOffset values that satisfy the > > restriction above. > > The channelOffset of a cell in the CellList SHOULD be randomly and > > uniformly in [0..numFrequencies] where numFrequencies represents > > the number of frequencies a node can communicate on. > > > Is this a format error...? > XV>> No, I think this is a bullet list with "invisible" bullets :) . We add the bullets. > > > 8. 6P Timeout Value > > > > > >The 6P Timeout is not a constant value. It is calculated a (C/ > >PDR)*6PTIMEOUT_SEC_FACTOR, where: > > > I think it'd be better for a variable name to start with a non-numeric > character even in a document. > > XV>> Agree. > That's it! > > Best, > Yatch > thanks Yatch! regards X > ___ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajos...@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
[6tisch] Comments on draft-chang-6tisch-msf-00
Hi all, I'd like to share my comments on draft-chang-6tisch-msf-00: https://tools.ietf.org/html/draft-chang-6tisch-msf-00 The first one is about 6P CLEAR after detecting unreachability to a neighbor. > 3.8. Step 7 - Neighbor Polling > > (snip) > >When a neighbor is declared unreachable, the node MUST issue a 6P >CLEAR to that neighbor (which can fail at the link-layer), and MUST >remove all dedicated links with that neighbor from its own schedule. Why does the node have to issue a 6P CLEAR to a neighbor which is determined to be unreachable...? It just wastes time and energy of the initiator since this transaction will fail as the draft mentioned. I think it'd be fine to remove all the dedicated cells to the unreachable neighbor without 6P CLEAR. By the way, the term "cells" should be used instead of "links". Other comments are trivial. > 1. Introduction > > (snip) > >MSF is designed to operate in a wide range of application domains. >It is optimized for applications with regular upstream traffic (from >the nodes to the Internet). "The internet" sounds too specific. "From the nodes toward the root" would be better? > 2. Interface to the Minimal 6TiSCH Configuration > > (snip) > >MSF uses the minimal cell to exchange the following packets: > > ... > >4. The first 6P packet a node issues to a neighbor it doesn't have >dedicated cells to, as defined by >[I-D.ietf-6tisch-6top-protocol]. These are unicast frames. The minimal cell is used for not only the first 6P packet but also subsequent packets associated with a 6P transaction initiated by the first packet. In this sense, I'd like to propose to replace it with: 6P packets to schedule the first dedicated cell with a neighbor. There are unicast frames. > 7. Rules for CellList > > >MSF uses 2-step 6P Transactions exclusively. 6P Transactions are >only initiated by a node towards it preferred parent. As a result, >the cells to put in the CellList of a 6P ADD command, and in the >candidate CellList of a RELOCATE command, are chosen by the node. In >both cases, the same rules apply: > > the CellList SHOULD contain 5 or more cells. > Each cell in the CellList MUST have a different slotOffset value. > For each cell in the CellList, the node MUST NOT have any > scheduled cell on the same slotOffset. > The slotOffset value of any cell in the CellList MUST NOT be the > same as the slotOffset of the minimal cell (slotOffset=0). > The slotOffset of a cell in the CellList SHOULD be randomly and > uniformly chosen among all the slotOffset values that satisfy the > restriction above. > The channelOffset of a cell in the CellList SHOULD be randomly and > uniformly in [0..numFrequencies] where numFrequencies represents > the number of frequencies a node can communicate on. Is this a format error...? > 8. 6P Timeout Value > > >The 6P Timeout is not a constant value. It is calculated a (C/ >PDR)*6PTIMEOUT_SEC_FACTOR, where: I think it'd be better for a variable name to start with a non-numeric character even in a document. That's it! Best, Yatch ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch