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

yanshen <yanshen@huawei.com> Tue, 15 August 2017 12:25 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 E25AC120721 for <idnet@ietfa.amsl.com>; Tue, 15 Aug 2017 05:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 KZKxWRLq-JbI for <idnet@ietfa.amsl.com>; Tue, 15 Aug 2017 05:25:54 -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 57B6512008A for <idnet@ietf.org>; Tue, 15 Aug 2017 05:25:53 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTL90777; Tue, 15 Aug 2017 12:25:51 +0000 (GMT)
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 15 Aug 2017 13:25:49 +0100
Received: from DGGEMM505-MBX.china.huawei.com ([169.254.1.229]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Tue, 15 Aug 2017 20:25:07 +0800
From: yanshen <yanshen@huawei.com>
To: Oscar Mauricio Caicedo Rendon <omcaicedo@unicauca.edu.co>
CC: "idnet@ietf.org" <idnet@ietf.org>
Thread-Topic: [Idnet] Summary 20170814 & IDN dedicated session call for case
Thread-Index: AdMUrc8Ikmqfd+z8QxaI3D4f5YkgmgAbomeg//+FaQD//kAzIA==
Date: Tue, 15 Aug 2017 12:25:06 +0000
Message-ID: <6AE399511121AB42A34ACEF7BF25B4D2986923@DGGEMM505-MBX.china.huawei.com>
References: <6AE399511121AB42A34ACEF7BF25B4D2982F34@DGGEMM505-MBX.china.huawei.com> <78A2745BE9B57D4F9D27F86655EB87F92599490E@SJCEML701-CHM.china.huawei.com> <CABo5upW44C=amiX8mD0Jc2JyyxwYRY5DROrrnexNOMnnT_HQbw@mail.gmail.com>
In-Reply-To: <CABo5upW44C=amiX8mD0Jc2JyyxwYRY5DROrrnexNOMnnT_HQbw@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: multipart/alternative; boundary="_000_6AE399511121AB42A34ACEF7BF25B4D2986923DGGEMM505MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5992E84F.0041, 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/Evr2UVRT2QlBG-LCjJxZipf1o0M>
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 12:25:59 -0000

Hi Oscar,

There are quite numbers of schemes that related with NFV scenario.

Personally, this case can be concluded into “resource allocation”. Not only the VNF resource, but also other resource. Such as,
         * In Data Center Network, the link resource or bandwidth allocation.
         * In the gateway device, the bandwidth allocation of different applications / priorities / subscribers / ports / etc…
         * TBD

I think that the basic ideas of these cases are similar: real-time measuring -> training -> optimizing the key characters -> next iteration. The difference is that they focus on various parameters. So this class questions can become a typical case.

Just my two cents.

Regards,

Yansen


From: Oscar Mauricio Caicedo Rendon [mailto:omcaicedo@unicauca.edu.co]
Sent: Tuesday, August 15, 2017 1:24 AM
To: Haoyu song <haoyu.song@huawei.com>;
Cc: yanshen <yanshen@huawei.com>;; idnet@ietf.org
Subject: Re: [Idnet] Summary 20170814 & IDN dedicated session call for case

Dear all,

Scaling mechanisms in NFV can leverage ML features. For instance, Reinforcement Learning could be used to tune policies of VNFs scaling (in memory, processing, number of instances, and so on), targeted to improve VNFs performance.

Oscar

On Mon, Aug 14, 2017 at 11:47 AM, Haoyu song <haoyu.song@huawei.com<mailto: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<mailto:idnet-bounces@ietf.org>] On Behalf Of yanshen
Sent: Sunday, August 13, 2017 8:36 PM
To: idnet@ietf.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:jerome.francois@inria.fr>; mskim16@etri.re.kr<mailto: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<mailto: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<mailto:IDNET@ietf.org>
https://www.ietf.org/mailman/listinfo/idnet



--
Oscar Mauricio Caicedo Rendón
PhD Computer Science - Federal University of Rio Grande do Sul
Full Profesor - University of Cauca

________________________________

Hacia una Universidad comprometida con la Paz Territorial