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

yanshen <yanshen@huawei.com> Wed, 16 August 2017 14:26 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 10C78126CB6 for <idnet@ietfa.amsl.com>; Wed, 16 Aug 2017 07:26:38 -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, 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] 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 nQryqgMb_hKa for <idnet@ietfa.amsl.com>; Wed, 16 Aug 2017 07:26:35 -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 3A2671321AE for <idnet@ietf.org>; Wed, 16 Aug 2017 07:26:34 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTO01832; Wed, 16 Aug 2017 14:26:31 +0000 (GMT)
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 16 Aug 2017 15:26:27 +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; Wed, 16 Aug 2017 22:25:54 +0800
From: yanshen <yanshen@huawei.com>
To: Hesham ElBakoury <Hesham.ElBakoury@huawei.com>
CC: "idnet@ietf.org" <idnet@ietf.org>
Thread-Topic: Summary 20170814 & IDN dedicated session call for case
Thread-Index: AdMUrc8Ikmqfd+z8QxaI3D4f5YkgmgBFDo4AABo54cA=
Date: Wed, 16 Aug 2017 14:25:53 +0000
Message-ID: <6AE399511121AB42A34ACEF7BF25B4D298714C@DGGEMM505-MBX.china.huawei.com>
References: <6AE399511121AB42A34ACEF7BF25B4D2982F34@DGGEMM505-MBX.china.huawei.com> <C3855D43D6701846AD1151A536E7A05824700491@SJCEML701-CHM.china.huawei.com>
In-Reply-To: <C3855D43D6701846AD1151A536E7A05824700491@SJCEML701-CHM.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.110.25]
Content-Type: multipart/alternative; boundary="_000_6AE399511121AB42A34ACEF7BF25B4D298714CDGGEMM505MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59945618.018F, 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: 6e8070943f36dfba4ff02f5725b4f6b6
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/hT7bvDuWrIVyPeM0xZlHyUjr8ag>
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: Wed, 16 Aug 2017 14:26:38 -0000

Hi Hesham,

I think this question seems simple but really significant. Please forgive if the answer was redundant. And it is welcome to point out my lacks if you have some different views.

In general, the new method may bring potential benefits. There had been some discussions before in our mail list. Please search the keyword "benefit" and check the result. But what I want to describe here are the following several points.

Firstly, in essence, the AI method can solve the scalability problem in each use case but existing methods cannot. In other words, the existing methods can hardly cover the complexity along with the huge increment of service in the future by repeating the current solutions multi-times.  For example, if the cost (including time and economic) of configuring a VPN is C, so that it will cost at least 100*C for 100 VPNs (this is ideal, it is even worse in practice). Even though somebody may say the software programs can also provide the automatic solution for this problems, but the over-linear incremental complexity will easily breakthrough the upper cost limit of  that we can pay. However, since the AI method may solve the same question in yet another new way so that it may change the complexity from over-linear growth to logarithmic growth (or even lower). This is significant because the current methods and their improved version can hardly implement such a change. I think this is one of the core problems that AI solves. It builds up a new pattern that can bear the pressure from new services and new requirements, which the traditional method cannot support.

Secondly, the new method can increase the automation level of the network but not only provide an automatic program. The AI method can make more process automatic such as the decision and policy deploying. Some of them cannot be implemented by program. For example, if we plan to capture and modify a series of devices/networks configuration, how can we implement that? The devices may be from different venders. The topology may be different. Their interfaces may be different. This situation is hard to solve by "if-else-then" logic or very hard. However, if we can abstract the configuration and the policies with some unified expression, such as using standard 0-1 series or formatted packet, the consulting between various devices will be simplified a lot. Of course, the "if-else-then" logic can implement that but the core of problem is the complexity.

However, some of the cases should not be mentioned. The aim of IDNet is introducing AI to serve the Network but not Application. Therefore, any case, whose output implements only a new function or new application, may be not suitable (personal view). Because it might be hardly produced by existing method but it is only a new tool but does not serve the network. We should focus on the case, whose output produces a decision, a strategy, or a configuration relative with network/device, or the cases that directly serve the Network Management, especially improving the efficiency and decreasing the cost. They are valuable.  So the answer may not depend on whether the existing methods can or cannot, but depends on the AI can or cannot provide a new form.

BTW, the new AI method may perform "better" than existing solutions. But in my opinion, this "better" cannot become the sufficient condition to apply because it is often covered by the cost of deployment.

In a word, in any cases, the IDNet will provide a scalability solutions and increase the automation level that the existing method and automatic software programs cannot. And our work here is to explore the standardization points and define the process, the data format, the architecture and etc., which support the compatibility for the various function entities. So that make the AI method enlarge the power of the network.


Regards,

Yansen

From: Hesham ElBakoury
Sent: Tuesday, August 15, 2017 8:49 PM
To: yanshen <yanshen@huawei.com>;; idnet@ietf.org
Subject: RE: Summary 20170814 & IDN dedicated session call for case

Hi Yanshen,

In all of these use cases what problems we are trying to solve that have not been solved before or why existing solutions are not good enough ?

Thanks

Hesham

From: IDNET [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