Re: [Idnet] Summary 20170814 & IDN dedicated session call for case

yanshen <yanshen@huawei.com> Tue, 15 August 2017 02:38 UTC

Return-Path: <yanshen@huawei.com>
X-Original-To: idnet@ietfa.amsl.com
Delivered-To: idnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE811324A1 for <idnet@ietfa.amsl.com>; Mon, 14 Aug 2017 19:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 GCuMNIuyxS4A for <idnet@ietfa.amsl.com>; Mon, 14 Aug 2017 19:38:07 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F7F1324B0 for <idnet@ietf.org>; Mon, 14 Aug 2017 19:38:05 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTK95944; Tue, 15 Aug 2017 02:38:03 +0000 (GMT)
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 15 Aug 2017 03:38:02 +0100
Received: from DGGEMM505-MBX.china.huawei.com ([169.254.1.229]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Tue, 15 Aug 2017 10:37:51 +0800
From: yanshen <yanshen@huawei.com>
To: Stenio Fernandes <sflf@cin.ufpe.br>, Haoyu song <haoyu.song@huawei.com>
CC: "idnet@ietf.org" <idnet@ietf.org>
Thread-Topic: [Idnet] Summary 20170814 & IDN dedicated session call for case
Thread-Index: AdMUrc8Ikmqfd+z8QxaI3D4f5YkgmgAbomeg//+R/gD//vUlAA==
Date: Tue, 15 Aug 2017 02:37:51 +0000
Message-ID: <6AE399511121AB42A34ACEF7BF25B4D298461D@DGGEMM505-MBX.china.huawei.com>
References: <6AE399511121AB42A34ACEF7BF25B4D2982F34@DGGEMM505-MBX.china.huawei.com> <78A2745BE9B57D4F9D27F86655EB87F92599490E@SJCEML701-CHM.china.huawei.com> <CAPrseCrzJUfo==ATt9TZeqtXfNvR4XkPNTvVO5G_8TBn_pBnRg@mail.gmail.com>
In-Reply-To: <CAPrseCrzJUfo==ATt9TZeqtXfNvR4XkPNTvVO5G_8TBn_pBnRg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.179.89]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.59925E8C.0031, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.229, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 33e7d71d2678e87b375ff97fda67f005
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/QaGhnHCDvYTeWo0BVWqpBSknyaU>
Subject: Re: [Idnet] Summary 20170814 & IDN dedicated session call for case
X-BeenThere: idnet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The IDNet \(Intelligence-Defined Network\) " <idnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idnet>, <mailto:idnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idnet/>
List-Post: <mailto:idnet@ietf.org>
List-Help: <mailto:idnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idnet>, <mailto:idnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Aug 2017 02:38:11 -0000

Hi Haoyu,

Agree. These two crucial cases in Network Management are what we are focusing on now. Since we plan to organize a dedicated session in NMRG, all the discussion will converge to the area of Network Management before Nov. 

Just expect Stenio's output few days later : )

Yansen


> -----Original Message-----
> From: steniofernandes@gmail.com [mailto:steniofernandes@gmail.com] On
> Behalf Of Stenio Fernandes
> Sent: Tuesday, August 15, 2017 2:09 AM
> To: Haoyu song <haoyu.song@huawei.com>
> Cc: yanshen <yanshen@huawei.com>om>; idnet@ietf.org
> Subject: Re: [Idnet] Summary 20170814 & IDN dedicated session call for case
> 
> Haoyu,
> 
> I'm working on the anomaly detection use case and will send it to the list this
> week.
> 
> Stenio
> 
> On Mon, Aug 14, 2017 at 12:47 PM, Haoyu song <haoyu.song@huawei.com>
> wrote:
> > Yansen,
> >
> >
> >
> > I see two key use cases are missing in the current list: root cause
> > analysis and anomaly detection. Those two are likely to use ML-based
> > solutions and the first one has already received a lot of research.
> >
> >
> >
> > Haoyu
> >
> >
> >
> > From: IDNET [mailto:idnet-bounces@ietf.org] On Behalf Of yanshen
> > Sent: Sunday, August 13, 2017 8:36 PM
> > To: idnet@ietf.org
> > Subject: [Idnet] Summary 20170814 & IDN dedicated session call for
> > case
> >
> >
> >
> > Dear all,
> >
> >
> >
> > Here is a summary and some index (2017.08.14). Till now, whatever the
> > case is supported or not, I tried to organize all the content and keep
> > the core part. It is still welcome to contribute and discuss.
> >
> >
> >
> > If I miss something important, please let me know. Apologized in advance.
> >
> >
> >
> > Yansen
> >
> >
> >
> >
> >
> > ---------  Roadmap  ---------
> >
> > ***Aug. : Collecting the use cases (related with NM). Rough thoughts
> > and requirements
> >
> > Sep. : Refining the cases and abstract the common elements
> >
> > Oct. : Deeply analysis. Especially on Data Format, control flow, or
> > other key points
> >
> > Nov.: F2F discussions on IETF100
> >
> > ---------  Roadmap End  ---------
> >
> >
> >
> >
> >
> > 1. Gap and Requirement Analysis
> >
> >     1.1 Network Management requirement
> >
> >     1.2 TBD
> >
> > 2. Use Cases
> >
> >     2.1 Traffic Prediction
> >
> >                    Proposed by: yanshen@huawei.com
> >
> >                    Track:
> > https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html
> >
> >                    Abstract: Collect the history traffic data and
> > external data which may influence the traffic. Predict the traffic in
> > short/long/specific term. Avoid the congestion or risk in previously.
> >
> >
> >
> >     2.2 QoS Management
> >
> >                    Proposed by: yanshen@huawei.com
> >
> >                    Track:
> > https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html
> >
> >                    Abstract: Use multiple paths to distribute the
> > traffic flows. Adjust the percentages. Avoid congestion and ensure QoS.
> >
> >
> >
> >     2.3 Application (and/or DDoS) detection
> >
> >                    Proposed by: aydinulas@gmx.net
> >
> >                    Track:
> > https://www.ietf.org/mail-archive/web/idnet/current/msg00133.html
> >
> >                    Abstract: Detect the application (or attack) from
> > network packets (HTTPS or plain) Collect the history traffic data and
> > identify a service or attack (ex: Skype, Viber, DDoS attack etc.)
> >
> >
> >
> >          2.4 QoE Management
> >
> >                    Proposed by: albert.cabellos@gmail.com
> >
> >                    Track:
> > https://www.ietf.org/mail-archive/web/idnet/current/msg00137.html
> >
> >                    Abstract: Collect low-level metrics (SNR, latency,
> > jitter, losses, etc) and measure QoE. Then use ML to understand what
> > is the relation between satisfactory QoE and the low-level metrics. As
> > an example learn that when delay>N then QoE is degraded, but when
> > M<delay<N then QoE is satisfactory for the customers (please note that
> > QoE cannot be measured directly over your network). This is useful to
> > understand how the network must be operated to provide satisfactory QoE.
> >
> >
> >
> >          2.5 (Encrypted) Traffic Classification
> >
> >                    Proposed by: jerome.francois@inria.fr;
> > mskim16@etri.re.kr
> >
> >                    Track: [Jerome]
> > https://www.ietf.org/mail-archive/web/idnet/current/msg00141.html ;
> > [Min-Suk Kim]
> > https://www.ietf.org/mail-archive/web/idnet/current/msg00153.html
> >
> >                    Abstract:
> >
> >                             [Jerome] collect flow-level traffic
> > metrics such as protocol information but also meta metrics such as
> > distribution of packet sizes, inter-arrival times... Then use such
> > information to label the traffic with the underlying application
> > assuming that the granularity of classification may vary (type of
> > application, exact application name,
> > version...)
> >
> >                             [Min-Suk Kim] continuously collect packet
> > data, then applying learning process for traffic classification with
> > generating application using deep learning models such as CNN
> > (convolutional neural
> > network) and RNN (recurrent neural network). Data-set to apply into
> > the models are generated by processing with features of information
> > from flow in packet data.
> >
> >
> >
> >          2.6 TBD
> >
> >
> >
> > 3. Data Focus
> >
> >     3.1 Data attribute
> >
> >     3.2 Data format
> >
> >     3.3 TBD
> >
> >
> >
> > 4. Support Technologies
> >
> >     4.1 Benchmarking Framework
> >
> >                    Proposed by: pedro@nict.go.jp
> >
> >                    Track:
> > https://www.ietf.org/mail-archive/web/idnet/current/msg00146.html
> >
> >                    Abstract: A proper benchmarking framework
> comprises
> > a set of reference procedures, methods, and models that can (or better
> > *must*) be followed to assess the quality of an AI mechanism proposed
> > to be applied to the network management/control area. Moreover, and
> > much more specific to the IDNET topics, is the inclusion, dependency,
> > or just the general relation of a standard format enforced to the data
> > that is used (input) and produced
> > (output) by the framework, so a kind of "data market" can arise
> > without requiring to transform the data. The initial scope of
> > input/output data would be the datasets, but also the new knowledge
> > items that are stated as a result of applying the benchmarking
> > procedures defined by the framework, which can be collected together
> > to build a database of benchmark results, or just contrasted with
> > other existing entries in the database to know the position of the
> > solution just evaluated. This increases the usefulness of IDNET.
> >
> >
> >
> >     4.2 TBD
> >
> >
> > _______________________________________________
> > IDNET mailing list
> > IDNET@ietf.org
> > https://www.ietf.org/mailman/listinfo/idnet
> >
> 
> 
> 
> --
> Prof. Stenio Fernandes
> CIn/UFPE
> http://www.steniofernandes.com