Re: [Idnet] IDN dedicated session call for case

Jérôme François <jerome.francois@inria.fr> Tue, 08 August 2017 14:40 UTC

Return-Path: <jerome.francois@inria.fr>
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 D10F9132545 for <idnet@ietfa.amsl.com>; Tue, 8 Aug 2017 07:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 zxCrfSCKcret for <idnet@ietfa.amsl.com>; Tue, 8 Aug 2017 07:40:14 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5426913253D for <idnet@ietf.org>; Tue, 8 Aug 2017 07:40:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.41,343,1498514400"; d="scan'208,217";a="286473824"
Received: from unknown (HELO [192.168.1.108]) ([89.130.180.250]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 08 Aug 2017 16:40:10 +0200
To: Aydin Ulas <aydinulas@gmx.net>, yanshen <yanshen@huawei.com>, "idnet@ietf.org" <idnet@ietf.org>
References: <6AE399511121AB42A34ACEF7BF25B4D297A34A@DGGEMM505-MBS.china.huawei.com> <HE1PR0701MB2203FC7F918350B07EBB65F0E8B00@HE1PR0701MB2203.eurprd07.prod.outlook.com> <CA+kz0z0yysZptZaZ-6ERKbQXC+tXncOtSjEY9Y3VtTrB4YvN7g@mail.gmail.com>
From: Jérôme François <jerome.francois@inria.fr>
Message-ID: <2af1096e-6cb9-7a69-3373-be3b70099bea@inria.fr>
Date: Tue, 08 Aug 2017 16:40:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CA+kz0z0yysZptZaZ-6ERKbQXC+tXncOtSjEY9Y3VtTrB4YvN7g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------21734C1A2863F82BAF4DCCF0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/RraCWanEW3-SiJvfyEKGHkL2Hvk>
Subject: Re: [Idnet] 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, 08 Aug 2017 14:40:17 -0000

Hi,

I support this use case and suggest to also include DDoS mitigation as
part of the process, e.g. re-routing to DPI middleboxes / blocking
traffic. You can thus evaluate the result of your mitigation decision
and readjust your model accordingly with reinforcement learning.
We have some on-going work in this area.

Best regards,
jerome


Le 02/08/2017 à 15:22, Aydin Ulas a écrit :
> Hi,
> Here is my suggestion.
>
> Use case N+1: Application (and/or DDoS) detection
>         Description: 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.)
>         Process: 1. Data collection (e.g. traffic sample of
> application to be detected or attack dump); 2. Training Model
> (includes data correlation from different parts of the network); 3.
> Real-time data capture and input; 4. Output prediction; 5. Online or
> periodically updating model parameters according to changes in the
> application (or attack style) 
>         Data Format:   Time: [Timestamp, ...]
>                                 Data Packet: [Packet Header, optional:
> Packet Content or the first few bytes: src/dst ip, src/dst port, frame
> length/number, ...]
>                                 Direction: IN / OUT
>                                 Route : [R1, R2, ..., RN] 
>                                 Traffic: [T0, T1, T2, ..., TN]
>
>         Message :       Request: ask for the data
>                                 Reply: Identification of application
>                                 Notice: For notification or others
>                                 Policy: Control policy
>
>
> Best regards,
> Aydin
>
> On Wed, Aug 2, 2017 at 3:35 PM, Ciavaglia, Laurent (Nokia - FR/Nozay)
> <laurent.ciavaglia@nokia-bell-labs.com
> <mailto:laurent.ciavaglia@nokia-bell-labs.com>> wrote:
>
>     Hello,
>
>     Hint: it would be nice to contact the NMRG chairs regarding the
>     dedicated session you are mentioning.
>     Also, participants of the NMRG could/should be interested/aware
>     and could eventually contribute to the effort.
>
>     Thanks, Laurent (as NMRG co-chair).
>     ---
>
>     -----Original Message-----
>     From: IDNET [mailto:idnet-bounces@ietf.org
>     <mailto:idnet-bounces@ietf.org>] On Behalf Of yanshen
>     Sent: Wednesday, August 02, 2017 12:12 PM
>     To: idnet@ietf.org <mailto:idnet@ietf.org>
>     Subject: [Idnet] IDN dedicated session call for case
>
>     Dear all,
>
>     Since we plan to organize a dedicated session in NMRG, IETF100,
>     for applying AI into network management (NM), I’d try to list some
>     Use Cases and propose a roadmap and ToC before Nov.
>
>     These might be rough. You are welcome to refine them and propose
>     your focused use cases or ideas.
>
>     Use case 1: Traffic Prediction
>             Description: 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.
>             Process: 1. Data collection (e.g. traffic sample of
>     physical/logical port ); 2. Training Model; 3. Real-time data
>     capture and input; 4. Predication output; 5. Fix error and go back
>     to 3.
>             Data Format:    Time : [Start, End, Unit, Number of Value,
>     Sampling Period]
>                                     Position: [Device ID, Port ID]
>                                     Direction: IN / OUT
>                                     Route : [R1, R2, ..., RN]  (might
>     be useful for some scenarios)
>                                     Service : [Service ID, Priority,
>     ...]  (Not clear how to use it but seems useful)
>                                     Traffic: [T0, T1, T2, ..., TN]
>             Message :       Request: ask for the data
>                                     Reply: Data
>                                     Notice: For notification or others
>                                     Policy: Control policy
>
>     Use case 2: QoS Management
>             Description: Use multiple paths to distribute the traffic
>     flows. Adjust the percentages. Avoid congestion and ensure QoS.
>             Process: 1. Data capture (e.g. traffic sample of
>     physical/logical port ); 2. Training Model; 3. Real-time data
>     capture and input; 4. Output percentages; 5. Fix error and go back
>     to 3.
>             Data Format:    Time : [Timestamp, Value type
>     (Delay/Packet Loss/...), Unit, Number of Value, Sampling Period]
>                                     Position: [Link ID, Device ID]
>                                     Value: [V0, V1, V2, ..., VN]
>             Message :       Request: ask for the data
>                                     Reply: Data
>                                     Notice: For notification or others
>                                     Policy: Control policy
>
>     Use case N: Waiting for your Ideas
>
>     Also I suggest a roadmap before Nov if possible.
>
>     ### 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 ###
>
>     A rough ToC is listed in following. We may take it as a scope
>     before Nov. Hope that the content could become the draft of draft.
>
>     ###Table of Content###
>     1. Gap and Requirement Analysis
>             1.1 Network Management requirement
>             1.2 TBD
>     2. Use Cases
>             2.1 Traffic Prediction
>             2.2 QoS Management
>             3.3 TBD
>     3. Data Focus
>             3.1 Data attribute
>             3.2 Data format
>             3.3 TBD
>     4. Aims
>             4.1 Benchmarking Framework
>             4.2 TBD
>     ###ToC End###
>
>
>     Yansen
>
>     _______________________________________________
>     IDNET mailing list
>     IDNET@ietf.org <mailto:IDNET@ietf.org>
>     https://www.ietf.org/mailman/listinfo/idnet
>     <https://www.ietf.org/mailman/listinfo/idnet>
>     _______________________________________________
>     IDNET mailing list
>     IDNET@ietf.org <mailto:IDNET@ietf.org>
>     https://www.ietf.org/mailman/listinfo/idnet
>     <https://www.ietf.org/mailman/listinfo/idnet>
>
>
>
>
> _______________________________________________
> IDNET mailing list
> IDNET@ietf.org
> https://www.ietf.org/mailman/listinfo/idnet