Re: [6tisch] New Version Notification for draft-karaagac-6tisch-int-00.txt

[<[e-mail]>]

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:[e-mail]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Tuesday, January 14, 2020 10:11 PM
> To: Abdulkadir Karaağaç (UGent-imec) <[e-mail]>;
> [e-mail]
> 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 <[e-mail]> On Behalf Of Abdulkadir
> > Karaagaç
> > (UGent-imec)
> > Sent: mardi 14 janvier 2020 10:43
> > To: [e-mail]
> > 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: [e-mail] <[e-mail]>
> > Sent: Saturday, January 11, 2020 23:21
> > To: Jeroen Hoebeke (UGent-imec) <[e-mail]>;
> Abdulkadir
> > Karaağaç (UGent-imec) <[e-mail]>
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/6tisch
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch