Re: [Idnet] IDN dedicated session call for case

Jérôme François <jerome.francois@inria.fr> Tue, 08 August 2017 14:59 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 58C631321E0 for <idnet@ietfa.amsl.com>; Tue, 8 Aug 2017 07:59:33 -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 RgqYqJ1EZanC for <idnet@ietfa.amsl.com>; Tue, 8 Aug 2017 07:59:30 -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 5192C1324E0 for <idnet@ietf.org>; Tue, 8 Aug 2017 07:59:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.41,343,1498514400"; d="scan'208,217";a="286476029"
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:59:23 +0200
To: "Diego R. Lopez" <diego.r.lopez@telefonica.com>, Albert Cabellos <albert.cabellos@gmail.com>, yanshen <yanshen@huawei.com>
References: <6AE399511121AB42A34ACEF7BF25B4D297A34A@DGGEMM505-MBS.china.huawei.com> <CAGE_QeztLKUF55OjKcsxqW=MUMAX60vR+6935-n+nnKPRVX2zg@mail.gmail.com> <7e6d507a-e8bf-b334-e394-6dc08b4dc3b1@inria.fr> <051F18D1-621A-4BF7-94F6-3C2D243F39C8@telefonica.com>
Cc: "idnet@ietf.org" <idnet@ietf.org>
From: =?UTF-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= <jerome.francois@inria.fr>
Message-ID: <02682a50-626b-bd60-bf96-14748d1783e0@inria.fr>
Date: Tue, 8 Aug 2017 16:59:19 +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: <051F18D1-621A-4BF7-94F6-3C2D243F39C8@telefonica.com>
Content-Type: multipart/alternative; boundary="------------864BE02D313F905C79C726E9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/5aph0fXwHxV20dJr4jWBXepJ4Ds>
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:59:33 -0000

100% agree with you. I was far from being exhaustive as traffic features
may depend on types of traffic (kin of sub use cases)

jerome
Le 08/08/2017 à 16:56, Diego R. Lopez a écrit :
>
> Hi Jerome,
>
>  
>
> Agreed. This is a use case we are very much interested in, and
> actually working in it now. Just let me say we are trying to evaluate
> which are the significant features of the flow to perform a proper
> classification, depending on the flow nature (TLS, DTLS, QUIC,
> IPsec…), and that would define the concrete data to be exchanged or
> stored.
>
>  
>
> Be goode,
>
>  
>
> --
>
> "Esta vez no fallaremos, Doctor Infierno"
>
>  
>
> Dr Diego R. Lopez
>
> Telefonica I+D
>
> http://people.tid.es/diego.lopez/
>
>  
>
> e-mail: diego.r.lopez@telefonica.com
>
> Tel:        +34 913 129 041
>
> Mobile: +34 682 051 091
>
> -----------------------------------
>
>  
>
> On 8/8/2017, 16:49 , "IDNET on behalf of Jérôme François"
> <idnet-bounces@ietf.org <mailto:idnet-bounces@ietf.org> on behalf of
> jerome.francois@inria.fr <mailto:jerome.francois@inria.fr>> wrote:
>
>  
>
> Hi all,
>
> Here is another use case about traffic classification.
>
> Use case N+3: (encrypted) traffic classification
>
>     Description: 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
> trafic with the underlying application assuming that the granularity
> of classification may vary (type of application, exact application
> name, version...)
>     Process: 1. collect packet information 2. flow reassembly (using
> directly flow format such as IPFIX might be possible but depends on
> the type of traffic, e.g. extracting the TLS application data is
> useful for encrypted traffic) 3. Collect application specific
> information (useful when targeting a single type of application) = out
> of network information 4. train the model 5. Online or offline testing
> 4. Apply application level policies.
>     Data Format:    Time : [Start, End, Unit, Number of Value,
> Sampling Period]
>                                 Position: [Device ID, Port ID]
>                                 Direction: IN / OUT
>                                 Flow level metric: packet size
> distributions, number of packets, inter-arrival time distribution,
>                                  (+ application specific knowledge :
> payload parsing)
>
>     Message :       Request: ask for the data
>                            Reply: Data
>                            Notice: For notification or others
>                            Policy: Control policy
>
>
> Best regards,
> jerome
>  
>
> Le 08/08/2017 à 06:52, Albert Cabellos a écrit :
>
>     Hi all
>
>      
>
>     Here´s another use-case:
>
>      
>
>     Use case N+2: QoE
>             Description: 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.
>             Process: 1. Low-level data collection and QoE measurement
>     ; 2. Training Model (input low-level metrics, output QoE); 3.
>     Real-time data capture and input; 4. Predict QoE; 5. Operate
>     network to meet target QoE requirement, go to 3.
>             Data Format:    Time : [Start, End, Unit, Number of Value,
>     Sampling Period]
>                                     Position: [Device ID, Port ID]
>                                     Direction: IN / OUT
>                                     Low-level metric : SNR, Delay,
>     Jitter, queue-size, etc
>
>
>             Message :       Request: ask for the data
>                                     Reply: Data
>                                     Notice: For notification or others
>                                     Policy: Control policy
>
>      
>
>     Kind regards
>
>      
>
>     Albert
>
>      
>
>     On Wed, Aug 2, 2017 at 7:12 PM, yanshen <yanshen@huawei.com
>     <mailto:yanshen@huawei.com>> wrote:
>
>         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
>
>      
>
>
>
>
>     _______________________________________________
>
>     IDNET mailing list
>
>     IDNET@ietf.org <mailto:IDNET@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/idnet
>
>
>
>
> ------------------------------------------------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su
> destinatario, puede contener información privilegiada o confidencial y
> es para uso exclusivo de la persona o entidad de destino. Si no es
> usted. el destinatario indicado, queda notificado de que la lectura,
> utilización, divulgación y/o copia sin autorización puede estar
> prohibida en virtud de la legislación vigente. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por
> esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual
> or entity named above. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited.
> If you have received this transmission in error, do not read it.
> Please immediately reply to the sender that you have received this
> communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> senhoria o destinatário indicado, fica notificado de que a leitura,
> utilização, divulgação e/ou cópia sem autorização pode estar proibida
> em virtude da legislação vigente. Se recebeu esta mensagem por erro,
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> proceda a sua destruição