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

Albert Cabellos <albert.cabellos@gmail.com> Fri, 18 August 2017 06:23 UTC

Return-Path: <albert.cabellos@gmail.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 78C7313239E for <idnet@ietfa.amsl.com>; Thu, 17 Aug 2017 23:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IXW3mRdYHF-e for <idnet@ietfa.amsl.com>; Thu, 17 Aug 2017 23:23:12 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 02C3212009C for <idnet@ietf.org>; Thu, 17 Aug 2017 23:23:12 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id n83so25781761ywn.2 for <idnet@ietf.org>; Thu, 17 Aug 2017 23:23:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7OQulWFk2Kzh9burjfz62JnFL0T01PaTBxQVZXX0R7c=; b=UfEKvOSQ5PLHgDsJa4EOOM9Xr+d+MfuCKV4TKty1Bi05CPNgrNr/knYzAi9cubZWKa ODbP24AzmDO1b23UY0Z8tUyGQ7ycIrS8YEza4ZPF5R2PYd8ZxNOlWFgjaEMiQqDUTAFG 2nIuGqjHqCuv7t1RkJcN8jcyE6dykCMWGtZEOPA1L6pSZ46w71eRdFH1s6fP+VmDB42v c/8h9PZVQhY2iB3qV1giGlRF4L65sEHP7d1FgyWChqrVYoyk787PWalewTf09jfZD5Ms o6hxIwm5CarcLxy2ltQ7YtNNReaQgSGYo5UkVnADoAdEzedAL6A3LHr/ij9VUmwXQlQL fA5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7OQulWFk2Kzh9burjfz62JnFL0T01PaTBxQVZXX0R7c=; b=nyDG1fl3qs0HITd95Mq5D1VGqzeovc0rsgda2suPD9gE3mvz9tQrQQgNI2xm88XIHj XiqOeoBrA0ihiT3lRJszxL/XSscq11nyLQ7Yb7Fl4+scIrWG8UNsbVzs8w9OqA4Rzrvz jYp8yUQ0FkRUSpMAQ3OsrEZkxXWk9ks7jeQJ3XS1xHldNE52ykcsrr+GGaM1KUY7X8wT Fyq9q5Crcyy7sXcOjgAS4wIq7duK60mlKCiEk5SXmD4fmHSVkwkNQoFXaGgsf4QYIdl9 5V28fvZZ7mkxaA3BHs1Dq18ukyqUFBs5mu2fYSjmypIsRjIvTDAj3Hm4DBWCBEbxTA+U 0MYg==
X-Gm-Message-State: AHYfb5gVydXAU3/I5cb5sLtGpxX3TjfDA2xgedjDTg7my2JLknWRLTdx S5IysKBLT55xGFr5lPvNfLnxCKo9zw==
X-Received: by 10.129.11.212 with SMTP id 203mr2253795ywl.62.1503037391120; Thu, 17 Aug 2017 23:23:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.172.141 with HTTP; Thu, 17 Aug 2017 23:23:10 -0700 (PDT)
In-Reply-To: <6AE399511121AB42A34ACEF7BF25B4D29872B1@DGGEMM505-MBX.china.huawei.com>
References: <6AE399511121AB42A34ACEF7BF25B4D2982F34@DGGEMM505-MBX.china.huawei.com> <C3855D43D6701846AD1151A536E7A05824700491@SJCEML701-CHM.china.huawei.com> <6AE399511121AB42A34ACEF7BF25B4D298714C@DGGEMM505-MBX.china.huawei.com> <C3855D43D6701846AD1151A536E7A0582470475A@SJCEML701-CHM.china.huawei.com> <6AE399511121AB42A34ACEF7BF25B4D29872B1@DGGEMM505-MBX.china.huawei.com>
From: Albert Cabellos <albert.cabellos@gmail.com>
Date: Fri, 18 Aug 2017 15:23:10 +0900
Message-ID: <CAGE_Qez2djTx46i402sXTcaH7=_gOe5JGiJK-LCOWo7VD6PZog@mail.gmail.com>
To: yanshen <yanshen@huawei.com>
Cc: Hesham ElBakoury <Hesham.ElBakoury@huawei.com>, "idnet@ietf.org" <idnet@ietf.org>
Content-Type: multipart/alternative; boundary="001a1142d4f8c82f700557012904"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/LKImST7EHsWDGOH_eXE8mdsUkkM>
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: Fri, 18 Aug 2017 06:23:15 -0000

Hi Hesham

Complementing what Yanshen mentioned:

ML (and specifically neural-nets) provide a modelling technique that work
very well with complex and/or nonlinear scenarios.

Traditional modeling techniques are analytical (e.g., markov chain, graph
models, etc) and computational models (e.g., simulators).

Analytical models do not work well with nonlinear behaviors and typically
require strong assumptions about the underlying hardware.

Simulator do not scale well with complexity, complex systems require long
development and/or runtimes.


ML work very well with nonlinear behaviors and scale very well with
complexity and dimensionality. The main drawback of ML techniques is the
training phase, for this you require a data-set and computational power.
Once trained the neural-net is lightweight and fast.


This has important advantages in optimization (QoS, VNF embedding) and
prediction (traffic, etc) scenarios.

Albert

On Thu, Aug 17, 2017 at 1:09 PM, yanshen <yanshen@huawei.com> wrote:

> Hi Hesham,
>
>
>
> Personal view. It is not important that whether the existing traffic
> recognizing methods are accurate or whether the problems are serious. We
> should focus on the previous and following steps. Whether we can abstract
> the data or process becoming a standard format? And how to transmit the
> result into the form that can be used in the following configuring process.
>
>
>
> Yansen
>
>
>
> *From:* Hesham ElBakoury
> *Sent:* Thursday, August 17, 2017 5:20 AM
> *To:* yanshen <yanshen@huawei.com>
>
> *Cc:* idnet@ietf.org
> *Subject:* RE: Summary 20170814 & IDN dedicated session call for case
>
>
>
> Hi Yansen,
>
>
>
> Thanks for your detailed response!
>
>
>
> There are also existing solutions which use AI/ML in (some of) these use
> cases. How our AI solutions will be better than existing AI solutions.
>
> Let us take classification of encrypted traffic as an example. There are
> already different solutions that use AI/ML to classify the encrypted
> traffic.
>
> What are the problems and shortcomings of these solutions  that should be
> addressed in new and better solutions which also use AI/ML ?
>
>
>
> Hesham
>
>
>
> *From:* yanshen
> *Sent:* Wednesday, August 16, 2017 7:26 AM
> *To:* Hesham ElBakoury
> *Cc:* idnet@ietf.org
> *Subject:* RE: Summary 20170814 & IDN dedicated session call for case
>
>
>
> 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 <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
>
>