Re: [Idnet] IDN dedicated session call for case

[Jérôme François <[e-mail]>]

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: [e-mail]
>
> Tel:        [phone]
>
> Mobile: [phone]
>
> -----------------------------------
>
>  
>
> On 8/8/2017, 16:49 , "IDNET on behalf of Jérôme François"
> <[e-mail] <mailto:[e-mail]> on behalf of
> [e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> 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
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/idnet
>
>      
>
>
>
>
>     _______________________________________________
>
>     IDNET mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     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