Hello Tengfei tions address is correct. Thanks!
“ During this step, the pledge MAY synchronize to any EB it receives from the network it wishes to join. “ In TSCH, time creates an event horizon whereby one only hears transmissions that start during guard time around the scheduled Rx time. If the text quoted above means only listen to timeslots that are aligned to the time in the particular EB, then the node will no more hear beacons that are not aligned with this. E.g., an attacker could offset EBs by 2ms from the network and nodes that synchronize will not hear other beacons any more. So a suggestion is that a node that listen to beacons does not synchronize till it has heard the count of beacons it is supposed to get. Thanks a lot for the comments. I have checked the sentence as what you suggested. Ø The text was not expected to become normative as is; obviously the usual ways apply like time out if some but not all beacons are received and sync to the best. Ø “ 8<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8>. Rules for CellList “ Maybe add a rule to listen to the cells for a few slotframes to ensure that they are not used by neighbors. This can be done proactively, like the node monitors the 5 randomly chosen cells all the time, even when there is no excess traffic, so a list of empty cells is ready when needed. I think it's not necessary to listen on the cells because when the 6P transaction starts , those cells should be locked and not be applied for other 6P transactions. * The point is that another pair of devices may have negotiated a cell that shows in the list, which you may discover if you screen the cells you want to use before you start using them. * It really depends if you have a pool of cells that you own (e.g., admin) or just grab them pseudorandomly. In the latter case no checking the cells is impolite, and checking them just before using them may miss a partial usage. Listening to a pool of cell even when you do not allocate them is safer. “ 6P Timeout Value “ I guess it is per peer? Shouldn’t it evolve like the RTO in RFC 6298 ? I think it's different from the RTO in RFC6298. In stead of traffic congestion control, the Timeout here is mostly influenced by one hop link quality. Which evolves and your value may track that, else it can be very big. Thanks a lot again for reviewing the draft and the comments! That’s a great spec : ) Pascal
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
