Hi, I have comments, some of which Pascal's email covers, though.
- L3 seems a better place to implement such a mechanism than L2. L2 has no idea whether the packet (frame) under process is going toward the border router nor not. - we need two Node IDs, source (sender) Node ID and destination (receiver) Node ID, to express a link - we may want 64-bit Node ID - Do you have an implementation of a scheduling algorithm using this proposal? I cannot immediately see how useful the default set of data defined in Table 1 is... Why isn't link PDR listed there...? I may miss something... pascal> It looks like you have implemented and tried it out already, correct? I'm interested in this part ;-) Best, Yatch > -----Original Message----- > From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Pascal Thubert > (pthubert) > Sent: Tuesday, January 14, 2020 10:11 PM > To: Abdulkadir Karaağaç (UGent-imec) <abdulkadir.karaa...@ugent.be>; > 6tisch@ietf.org > Subject: Re: [6tisch] New Version Notification for > draft-karaagac-6tisch-int-00.txt > > Dear authors > > This draft strikes me as very mature for a 00, and a very useful piece of > work as > well. > It looks like you have implemented and tried it out already, correct? > > A few comments and questions: > > * Since you are using IEs Fig 1 could represent the insertion before the IPv6 > payload. > * There could be a Fig describing the typical format of the inserted IE at > the end > of 2.2 > * A discussion on the chances of loss that are augmented as the frame are > enlarged could be useful in the intro > * A discussion of the INT header used as a hidden channel could be useful in > the security section > * It seems that the data can only be reported on packets that are going > outwards. You may want to indicate that in a classical non-storing network > with the root acting as backbone router, all packets fly through the 6BBR and > can be instrumented. > * Because of the Q bit it seems that the INT IE is also used in packets going > down: the source routing header may make it complicated to instrument such > packets. More description on the operation and size of inserted header in > downwards packets could be useful. Maybe we could make the query a > different IE altogether and save the Q bit for the future. > * If the telemetry relates to a transmission by a child, then the node ID is > not > enough to identify the link since the child has multiple parents. > * Apparently in HbH mode 1 only the first nodes may insert data if the network > is deep and the room limited. > * In HbH mode 2, how do we balance the use of the space so that all hops have > an equal chance to report their information? Is that what 2.3.1 is all about? > * In section 2.3 > ** I believe that if nodes use different strategies some may starve. Like for > the > objective function, there should be a single strategy, that may have to be > tuned > for the shape of the network. > ** in 2.3.1 if all nodes source traffic and not only the deepest ones, > actually the > nodes near the root may have more opportunities, it really depends on the > shape of the network. > ** in 2.3.2 we seem to assume that only nodes deep in the network source > packets. In reality, say that there can be 3 values stored, then the number of > chances is proportional to the number of children and grandchildren, and > nodes deep in the network may have less of these. > ** it could be good that a node that refrains to insert redundant information > may > still indicate that already sent information (sequence) is unchanged. Along > that line of thought how do we handle loss? A same sequence sent several > times? > * Security section should indicate that the payload IE is modified at each hop > and there is no guarantee that the original information is preserved > > Great work! > > Pascal > > > > > > > -----Original Message----- > > From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Abdulkadir > > Karaagaç > > (UGent-imec) > > Sent: mardi 14 janvier 2020 10:43 > > To: 6tisch@ietf.org > > Subject: [6tisch] FW: New Version Notification for > > draft-karaagac-6tisch-int- 00.txt > > > > Dear all, > > We have submitted a new draft describing an efficient and timely > > monitoring solution for 6TiSCH Networks. We believe that this > > mechanism can become a very powerful tool for 6TiSCH Networks with the > > contribution of the 6TiSCH community. > > > > All kinds of feedback and comments are very welcome. Thanks a lot! > > > > Kind regards, > > Abdulkadir > > > > > > -----Original Message----- > > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > > Sent: Saturday, January 11, 2020 23:21 > > To: Jeroen Hoebeke (UGent-imec) <jeroen.hoeb...@ugent.be>; > Abdulkadir > > Karaağaç (UGent-imec) <abdulkadir.karaa...@ugent.be> > > Subject: New Version Notification for draft-karaagac-6tisch-int-00.txt > > > > > > A new version of I-D, draft-karaagac-6tisch-int-00.txt has been > > successfully submitted by Abdulkadir Karaagac and posted to the IETF > repository. > > > > Name: draft-karaagac-6tisch-int > > Revision: 00 > > Title: In-band Network Telemetry for 6TiSCH Networks > > Document date: 2020-01-11 > > Group: Individual Submission > > Pages: 14 > > URL: > https://www.ietf.org/internet-drafts/draft-karaagac-6tisch-int- > > 00.txt > > Status: https://datatracker.ietf.org/doc/draft-karaagac-6tisch-int/ > > Htmlized: https://tools.ietf.org/html/draft-karaagac-6tisch-int-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-karaagac-6tisch-int > > > > > > Abstract: > > This document describes In-band Network Telemetry for 6TiSCH > > Networks, offering a flexible monitoring solution with minimal > > resource consumption and communication overhead while supporting a > > wide range of monitoring operations and strategies for dealing with > > various network scenarios and use cases. It enables 6TiSCH networks > > to collect per-packet and per-hop monitoring information by > > piggybacking telemetry information onto the data packets by > > exploiting the remaining space in the IEEE 802.15.4e frames, thus not > > impacting network behavior and performance. This document also > > discusses the data fields and associated data types for 6TiSCH INT > > mechanism. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > _______________________________________________ > > 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
