Re: [Idnet] IDN dedicated session call for case

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

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
>     <https://www.ietf.org/mailman/listinfo/idnet>
>
>
>
>
> _______________________________________________
> IDNET mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idnet