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

Oscar Mauricio Caicedo Rendon <omcaicedo@unicauca.edu.co> Mon, 14 August 2017 17:25 UTC

Return-Path: <omcaicedo@unicauca.edu.co>
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 69D451323AF for <idnet@ietfa.amsl.com>; Mon, 14 Aug 2017 10:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unicauca.edu.co
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 JheA1skbei8X for <idnet@ietfa.amsl.com>; Mon, 14 Aug 2017 10:25:08 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 4524E13226B for <idnet@ietf.org>; Mon, 14 Aug 2017 10:25:08 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id d29so39183971uai.2 for <idnet@ietf.org>; Mon, 14 Aug 2017 10:25:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unicauca.edu.co; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mDWXplNtAvI1SCexKMCyRs3ukuscJi3Kkh3RYHYKiXE=; b=NQepQItIqdK75gccpSVrpjLuajqj1CQ3UU4COr/IA3/S/gWhF8r0+GJMmeaBG/Vq1Y 4Qm5I9kC1SjI9g2zOTD2x8F/9oBILpcdcyyo+Bs8r2gxNFk21XEFUYJeiHpfEU8FUEpF /cehjmhK+80JkuvtcdXhODLHtAJ3p9Cl92p1o=
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=mDWXplNtAvI1SCexKMCyRs3ukuscJi3Kkh3RYHYKiXE=; b=XUP2kkaoKe4uEn/xpho9dx08ILp5p11hY3JGaZWQRKIpBbLYZFeMXaG8g0GKG4MM3A 6ZE6x+GAcP5yR1jH32xfEi/yoKchBlofPvYJAFZbPbFRW4Kj5TFwv0JjbsyCaIE9Bg+6 LsP3WU3W4cb95kq/rWdI+fYvr0TqakDMxhDtfMNjONHjcbBZYHudWUSt41jLebdF1HWG gKwVYC5SeLBPCrSZTNWiGpxTTSO2YS0R1BFSWqQvD4ESwRASiK4HtEA7aTPHjGrGBFJ/ kR23dy20kMGovQ7U1IYtDeHSlWn/p4f3d7uflN5qpdQ0R4Tl290QeRaCB9sj6XLoKUIM jMVg==
X-Gm-Message-State: AHYfb5horZ3AOsWGh0FVctWmLHLsqiDN06+uFhfdlsBPP8/pob1glewt JMfM/Nq3UAJSz5LU0omyCyl+7G5gOZvjd9scM+Ck20yMxlF1vtyKD5FyNa8833K5DSRjQYL4ZNg wo0hdYQ==
X-Received: by 10.176.80.193 with SMTP id d1mr17539136uaa.124.1502731507331; Mon, 14 Aug 2017 10:25:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.46.216 with HTTP; Mon, 14 Aug 2017 10:24:46 -0700 (PDT)
In-Reply-To: <78A2745BE9B57D4F9D27F86655EB87F92599490E@SJCEML701-CHM.china.huawei.com>
References: <6AE399511121AB42A34ACEF7BF25B4D2982F34@DGGEMM505-MBX.china.huawei.com> <78A2745BE9B57D4F9D27F86655EB87F92599490E@SJCEML701-CHM.china.huawei.com>
From: Oscar Mauricio Caicedo Rendon <omcaicedo@unicauca.edu.co>
Date: Mon, 14 Aug 2017 12:24:46 -0500
Message-ID: <CABo5upX6+4ZEo8mWyDMyDuFM3xLJzNKBjggEbR3AZpF8Sr0faA@mail.gmail.com>
To: Haoyu song <haoyu.song@huawei.com>
Cc: yanshen <yanshen@huawei.com>, "idnet@ietf.org" <idnet@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c19211eb05fdd0556b9f18b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/74BrpQcOaFnOVDGQLw3HgEAFVGg>
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: Mon, 14 Aug 2017 17:25:11 -0000

Dear all,

Scaling mechanisms in NFV can leverage ML features. In particular, for
instance, Reinforcement Learning could be used to tune policies scaling
target to

On Mon, Aug 14, 2017 at 11:47 AM, 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
>
>


-- 
*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*