Re: [Idnet] IDN dedicated session call for case

yanshen <yanshen@huawei.com> Wed, 09 August 2017 04:07 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 2F131131CF0 for <idnet@ietfa.amsl.com>; Tue, 8 Aug 2017 21:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RFog9-al7UXf for <idnet@ietfa.amsl.com>; Tue, 8 Aug 2017 21:07:33 -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 3DE1E124B18 for <idnet@ietf.org>; Tue, 8 Aug 2017 21:07:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMF74185; Wed, 09 Aug 2017 04:07:30 +0000 (GMT)
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 9 Aug 2017 05:07:29 +0100
Received: from DGGEMM505-MBS.china.huawei.com ([169.254.2.173]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Wed, 9 Aug 2017 12:07:23 +0800
From: yanshen <yanshen@huawei.com>
To: Stenio Fernandes <sflf@cin.ufpe.br>
CC: "Diego R. Lopez" <diego.r.lopez@telefonica.com>, Albert Cabellos <albert.cabellos@gmail.com>, "idnet@ietf.org" <idnet@ietf.org>, =?utf-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= <jerome.francois@inria.fr>
Thread-Topic: [Idnet] IDN dedicated session call for case
Thread-Index: AdMLcu+vuWBrdNuZQwG6l2oQPpJcKAETCHGAABTa8AAAAEJ2AAAAFQKAAAC+cIAAKpLegA==
Date: Wed, 9 Aug 2017 04:07:22 +0000
Message-ID: <6AE399511121AB42A34ACEF7BF25B4D297B362@DGGEMM505-MBS.china.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> <02682a50-626b-bd60-bf96-14748d1783e0@inria.fr> <CAPrseCrSCh3wsa4gWnmfv8t_rVw1TW0QpvEW4UrVykrc31Antg@mail.gmail.com>
In-Reply-To: <CAPrseCrSCh3wsa4gWnmfv8t_rVw1TW0QpvEW4UrVykrc31Antg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.179.89]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.598A8A82.00C2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.173, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fd7621320db95814aa6d78c44afb19fc
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/cb0tf8OhcOpAaWi5IHnLuY-uAZI>
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: Wed, 09 Aug 2017 04:07:36 -0000

Hi Stenio,

Recently I also think about that use un/supervised ML method to implement the routing process. 

May I suggest you to have a simple refining and push it into mail list ? Just roughly refer to the format.

It will be helpful for both the discussion and your future work. 

Yansen

> -----Original Message-----
> From: steniofernandes@gmail.com [mailto:steniofernandes@gmail.com] On
> Behalf Of Stenio Fernandes
> Sent: Tuesday, August 08, 2017 11:21 PM
> To: Jérôme François <jerome.francois@inria.fr>
> Cc: Diego R. Lopez <diego.r.lopez@telefonica.com>om>; Albert Cabellos
> <albert.cabellos@gmail.com>om>; yanshen <yanshen@huawei.com>om>; idnet@ietf.org
> Subject: Re: [Idnet] IDN dedicated session call for case
> 
> Hi Jerome, Diego, et al,
> 
> Those are excellent use cases. I have some published work on applied machine
> learning to computer networking problems, including flow-based traffic
> classification. I think another use case would be applying unsupervised learning
> techniques for anomaly detection. I can elaborate further on this.
> 
> Stenio
> 
> On Tue, Aug 8, 2017 at 10:59 AM, Jérôme François <jerome.francois@inria.fr>
> wrote:
> > 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 on behalf of 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> 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
> > https://www.ietf.org/mailman/listinfo/idnet
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> > IDNET mailing list
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > IDNET mailing list
> > IDNET@ietf.org
> > https://www.ietf.org/mailman/listinfo/idnet
> >
> 
> 
> 
> --
> Prof. Stenio Fernandes
> CIn/UFPE
> http://www.steniofernandes.com