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

<yatch1.tanaka@toshiba.co.jp> Tue, 14 January 2020 13:57 UTC

Return-Path: <yatch1.tanaka@toshiba.co.jp>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AF41200D7 for <6tisch@ietfa.amsl.com>; Tue, 14 Jan 2020 05:57:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AKkjfSZp6Wd for <6tisch@ietfa.amsl.com>; Tue, 14 Jan 2020 05:56:57 -0800 (PST)
Received: from mo-csw.securemx.jp (mo-csw1116.securemx.jp [210.130.202.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEC01200DF for <6tisch@ietf.org>; Tue, 14 Jan 2020 05:56:56 -0800 (PST)
Received: by mo-csw.securemx.jp (mx-mo-csw1116) id 00EDusCH025515; Tue, 14 Jan 2020 22:56:54 +0900
X-Iguazu-Qid: 2wHHIRGz1OqOLUVO9g
X-Iguazu-QSIG: v=2; s=0; t=1579010214; q=2wHHIRGz1OqOLUVO9g; m=Bi1H1YqFc9LUvEwLYr05Jq3khab58G29vzUEFVXvEJY=
Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) by relay.securemx.jp (mx-mr1110) id 00EDur0G030505; Tue, 14 Jan 2020 22:56:53 +0900
Received: from enc01.localdomain ([106.186.93.100]) by imx2.toshiba.co.jp with ESMTP id 00EDuru3014516; Tue, 14 Jan 2020 22:56:53 +0900 (JST)
Received: from hop001.toshiba.co.jp ([133.199.164.63]) by enc01.localdomain with ESMTP id 00EDur0H020407; Tue, 14 Jan 2020 22:56:53 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AY9YV8yHb6XtVPIihouHrUazl8EreKjgGL189gwJUgmZaWkUBSEyHKwYlC2huO39rYu9BbNdE+elUC2QtK5+fuXFARRM/rOFrWgbfedpZWkywHosgzwNgWY1o9oZj5pwrP8CVPxgbN58FmASGnEGbeDSYkSJ3pXQkYaUnHU4KFwyxZl88cBBSGoVtbMkq3rVJLOl1N9aMXQWnvieyqsXlvA/1i0p3zi+S75jwWX+LdNHeTS3I0t8UZww7gGNBfB96K5T2kIKQsNCG7AmPdinnsTCLs38Mk65znjcRbDC3eFuVvg4oRNqJcnSdgoCAUV/+aV75m5rxlj6MnSRk8qSYw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6oAgEX9zbTAPlklvoR4ZN/N+xCgCV8gOqQG1tjA8b6Y=; b=OcdzmjrKKwmHBkHjtIpCVSXyMgN5T1fe16wwdbwS3lhqtRVzUOx3BSdi6r3n9lLGH2500Le/8CCIHGfeovTM082w6DuWKcFW4DevnF71TdBsPlSmxh0Cr22LxcRaxeSnKz2zJCtZ+ZcEwld74R7/UrHdmHZlMSG+NQAihEfuWegeF9r5NhZzR5AgEAPniDurmpWLYxI/iZlcPS9n+sxJ86V/LgxilGADB1qkhlsHT84TCl8OBD8HcaRUCNqf/1EwR2SePIvDypqAIbjyKjuVbd7AaxJ+E0grsUEzdcVPuqHwbZh/5MD4AH7OtvaNN7LPvZki9aSxZpXjKzWRU/+spg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=toshiba.co.jp; dmarc=pass action=none header.from=toshiba.co.jp; dkim=pass header.d=toshiba.co.jp; arc=none
From: <yatch1.tanaka@toshiba.co.jp>
To: <Abdulkadir.Karaagac@UGent.be>
CC: <6tisch@ietf.org>, <yatch1.tanaka@toshiba.co.jp>
Thread-Topic: New Version Notification for draft-karaagac-6tisch-int-00.txt
Thread-Index: AQHVyM13PrqUP/PduEaydEgQyJyajqfp52BwgAAxwKCAABAkoA==
Date: Tue, 14 Jan 2020 13:56:50 +0000
X-TSB-HOP: ON
Message-ID: <TYAPR01MB29272A49DE133E0E4F7C7A26EE340@TYAPR01MB2927.jpnprd01.prod.outlook.com>
References: <157878128266.26084.13726261387928945335.idtracker@ietfa.amsl.com> <6197870a4dd542d292a355ff997feecb@xmail102.UGent.be> <BYAPR11MB35585A1221DC38AE1E1BF272D8340@BYAPR11MB3558.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB35585A1221DC38AE1E1BF272D8340@BYAPR11MB3558.namprd11.prod.outlook.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
authentication-results: spf=none (sender IP is ) smtp.mailfrom=yatch1.tanaka@toshiba.co.jp;
x-originating-ip: [220.219.148.14]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d088d2cb-28b2-47a3-c70b-08d798f99a85
x-ms-traffictypediagnostic: TYAPR01MB5117:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <TYAPR01MB511734A34EB5DCB66DCC81BFEE340@TYAPR01MB5117.jpnprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 028256169F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(199004)(189003)(15650500001)(6916009)(55016002)(9686003)(86362001)(2906002)(54906003)(4326008)(7696005)(5660300002)(81166006)(52536014)(107886003)(966005)(186003)(53546011)(66574012)(6506007)(26005)(8676002)(8936002)(498600001)(71200400001)(66946007)(33656002)(66556008)(64756008)(66476007)(66446008)(76116006)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:TYAPR01MB5117; H:TYAPR01MB2927.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: toshiba.co.jp does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Pp+J9U/1r2UmibFOdip153VYOuTv5LcF5CM1OEyX/Dx1ML44wq/4SVcatzn4xJ5T51AdMoBo/ypnNo35/Z45ARt7I5YMbJ2VPbs6IYAhZCm3UQABYET/UO2xkU6eOMkhK7rU0XNshfSQEFJs+prDPZ55lmrBeUCk186GUoy/FnYdMmVhxKanUyRconByJm42DAp9XdHXGOTKiUiI/pZ3MjeDqhipAOBnmAROgYXD2MWiaGYwk5L2WLaLD3o9NqNjb+11GwENF49FfqKQogvmgrmU6vIIx25Ur8e+yL1/P1co7nEQKH9G9+ahzHOFYgq3mgZTgQUMYKRjmFIz8baGy8prEuVb70/++tQhcylvPztz3kTlx+YUOOcAx0VZ39o2g8d8Oxtf+xdTo6XKFm01ovdCfP/2Mvm7U72kMYrnwrCIkytXKS92Cz7jhT4WqnBeG6UzdNm9ABCGm5QtjuX5JU49QBm9Dl087FFTsK5AumI=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d088d2cb-28b2-47a3-c70b-08d798f99a85
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 13:56:50.2012 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8sblJKm5Y0FdfSeiGnCyvrHFHMI93S1qtGtyRMyLNwjIhwKQgCgxwBYPVedVIVozf7YG8QVb3BDmmlj7TFyPkqx2bHaOZ2hFR8osmHqPHg0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB5117
X-OriginatorOrg: toshiba.co.jp
MSSCP.TransferMailToMossAgent: 103
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/v8s8EWgQX5SPHghlNXtv9-iLyPk>
Subject: Re: [6tisch] New Version Notification for draft-karaagac-6tisch-int-00.txt
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2020 13:57:02 -0000

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-bounces@ietf.org] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Tuesday, January 14, 2020 10:11 PM
> To: Abdulkadir Karaağaç (UGent-imec) <Abdulkadir.Karaagac@UGent.be>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-bounces@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-drafts@ietf.org <internet-drafts@ietf.org>
> > Sent: Saturday, January 11, 2020 23:21
> > To: Jeroen Hoebeke (UGent-imec) <Jeroen.Hoebeke@UGent.be>be>;
> Abdulkadir
> > Karaağaç (UGent-imec) <Abdulkadir.Karaagac@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