Subject: [Idnet] Applying AI into network management//FW: [nmrg] 45th NMRG meeting: Call for Contributions

From: Sheng Jiang <[email-masked]>
Date: Wed, 13 Sep 2017 14:19:43 +0000

Hi, IDNet,

After coordinating with NMRG chairs, a Call for Contributions message (see below) has been sent by them to the NMRG mailing list regarding to the topic of applying AI into network management. This is in line with our earlier discussion to have a session on this in NMRG, Singapore. You could send email to volunteer for presentations in either NMRG or IDNet mailing list (I will bridge to NMRG chairs in the IDNet case) or cross post.

Looking forward for your contributions and good discussion in Singapore.

Best regards,

Sheng

-----Original Message-----
From: nmrg [mailto:[email-masked]] On Behalf Of Lisandro Zambenedetti Granville
Sent: Wednesday, September 13, 2017 9:57 PM
To: [email-masked]
Subject: [nmrg] 45th NMRG meeting: Call for Contributions

Call for Contributions
45th NMRG meeting at IETF 100

In the next IETF100/Singapore we will be organizing the 45th NMRG meeting. We would like to center the upcoming meeting around the use of artificial intelligence (AI) for network management, including related topics as diverse as machine-learning and intelligent-defined networks, for example.

AI for network management is not a new topic, as can be easily observed in the literature produced by the network management community already years ago. On the other hand, AI has matured a lot, finding applications is several areas. People interested in the subject also formed communities that can contribute too. As such, revisiting AI for network management is not only appropriate but also timely. 

In this Call for Contributions we would like to receive proposals of presentations/discussions for the upcoming 45th NMRG meeting. That includes, for example:

- Use cases where AI could/should be used in network management
- Real-life experiments, results, and findings on AI for network management
- Disruptive and/or new management paradigms based on AI
- Potential standard requirements for applying AI for network management
- Both preliminary and mature approaches

Please contribute and feel free to distribute this call to other mailing lists whose members you believe would be interested and could contribute too.

Best regards, Lisandro and Laurent.
_______________________________________________
nmrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/nmrg

---

From: yanshen <[email-masked]>
Date: Tue, 19 Sep 2017 06:48:24 +0000

Hi Sheng, 

I would like to have a short presentation about the Use case of Traffic Prediction/QoS Model. 

My question is how to "register"? I directly send Email to the NMRG chair or we have a pre-registration in IDNet ?

I attach the brief summary of use cases in the end. Hope it helpful. 

Yansen

==========================================
1. Gap and Requirement Analysis
    1.1 Network Management requirement
    1.2 TBD
2. Use Cases
    2.1 Traffic Prediction
		Proposed by: [email-masked]
		Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html
		Abstract: 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.
		
    2.2 QoS Management
		Proposed by: [email-masked]
		Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html
		Abstract: Use multiple paths to distribute the traffic flows. Adjust the percentages. Avoid congestion and ensure QoS. 
	
    2.3 Application (and/or DDoS) detection
		Proposed by: [email-masked]
		Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00133.html
		Abstract: 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.)
	
	2.4 QoE Management
		Proposed by: [email-masked]
		Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00137.html
		Abstract: 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.
	
	2.5 (Encrypted) Traffic Classification
		Proposed by: [email-masked]; [email-masked]
		Track: [Jerome] https://www.ietf.org/mail-archive/web/idnet/current/msg00141.html ; [Min-Suk Kim] https://www.ietf.org/mail-archive/web/idnet/current/msg00153.html
		Abstract: 
			[Jerome] 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 traffic with the underlying application assuming that the granularity of classification may vary (type of application, exact application name, version...)
			[Min-Suk Kim]continuously collect packet data, then applying learning process for traffic classification with generating application using deep learning models such as CNN (convolutional neural network) and RNN (recurrent neural network). Data-set to apply into the models are generated by precessing with features of information from flow in packet data.
		
	2.6 Anomaly Detection
		Proposed by: [email-masked]
		Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00186.html
		Abstract: 
			[Jerome] 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 traffic with the underlying application assuming that the granularity of classification may vary (type of application, exact application name, version...)
			[Min-Suk Kim]continuously collect packet data, then applying learning process for traffic classification with generating application using deep learning models such as CNN (convolutional neural network) and RNN (recurrent neural network). Data-set to apply into the models are generated by precessing with features of information from flow in packet data.
	
3. Data Focus
    3.1 Data attribute
    3.2 Data format
    3.3 TBD
	
4. Support Technologies
    4.1 Benchmarking Framework
		Proposed by: [email-masked]
		Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00146.html
		Abstract: A proper benchmarking framework comprises a set of reference procedures, methods, and models that can (or better *must*) be followed to assess the quality of an AI mechanism proposed to be applied to the network management/control area. Moreover, and much more specific to the IDNET topics, is the inclusion, dependency, or just the general relation of a standard format enforced to the data that is used (input) and produced (output) by the framework, so a kind of "data market" can arise without requiring to transform the data. The initial scope of input/output data would be the datasets, but also the new knowledge items that are stated as a result of applying the benchmarking procedures defined by the framework, which can be collected together to build a database of benchmark results, or just contrasted with other existing entries in the database to know the position of the solution just evaluated. This increases the usefulness of IDNET.
	
    4.2 TBD

=========================================

> From: IDNET [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: Wednesday, September 13, 2017 10:20 PM
> To: [email-masked]
> Subject: [Idnet] Applying AI into network management//FW: [nmrg] 45th NMRG
> meeting: Call for Contributions
> 
> Hi, IDNet,
> 
> After coordinating with NMRG chairs, a Call for Contributions message (see
> below) has been sent by them to the NMRG mailing list regarding to the topic
> of applying AI into network management. This is in line with our earlier
> discussion to have a session on this in NMRG, Singapore. You could send email
> to volunteer for presentations in either NMRG or IDNet mailing list (I will bridge
> to NMRG chairs in the IDNet case) or cross post.
> 
> In the next IETF100/Singapore we will be organizing the 45th NMRG meeting.
> We would like to center the upcoming meeting around the use of artificial
> intelligence (AI) for network management, including related topics as diverse
> as machine-learning and intelligent-defined networks, for example.
> 
> AI for network management is not a new topic, as can be easily observed in the
> literature produced by the network management community already years ago.
> On the other hand, AI has matured a lot, finding applications is several areas.
> People interested in the subject also formed communities that can contribute
> too. As such, revisiting AI for network management is not only appropriate but
> also timely.
> 
> In this Call for Contributions we would like to receive proposals of
> presentations/discussions for the upcoming 45th NMRG meeting. That includes,
> for example:
> 
> Please contribute and feel free to distribute this call to other mailing lists
> whose members you believe would be interested and could contribute too.
> 
> IDNET mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idnet

---

From: "Ciavaglia, Laurent (Nokia - FR/Nozay)" <[email-masked]>
Date: Tue, 19 Sep 2017 07:34:02 +0000

Dear Yansen, all,

We (NMRG chairs) will coordinate with Sheng/IDNET for defining the agenda.
Please send your proposal to either lists.

Thanks, Laurent.

-----Original Message-----
From: IDNET [mailto:[email-masked]] On Behalf Of yanshen
Sent: Tuesday, September 19, 2017 8:48 AM
To: Sheng Jiang <[email-masked]>; [email-masked]
Subject: Re: [Idnet] Applying AI into network management//FW: [nmrg] 45th NMRG meeting: Call for Contributions

Hi Sheng, 

Yansen

    2.2 QoS Management

	2.4 QoE Management

	2.6 Anomaly Detection
	
3. Data Focus
    3.1 Data attribute
    3.2 Data format
    3.3 TBD
	
4. Support Technologies
	
    4.2 TBD

> below) has been sent by them to the NMRG mailing list regarding to the 
> topic of applying AI into network management. This is in line with our 
> earlier discussion to have a session on this in NMRG, Singapore. You 
> could send email to volunteer for presentations in either NMRG or 
> IDNet mailing list (I will bridge to NMRG chairs in the IDNet case) or cross post.
> 
> We would like to center the upcoming meeting around the use of 
> artificial intelligence (AI) for network management, including related 
> topics as diverse as machine-learning and intelligent-defined networks, for example.
> 
> AI for network management is not a new topic, as can be easily 
> observed in the literature produced by the network management community already years ago.
> People interested in the subject also formed communities that can 
> contribute too. As such, revisiting AI for network management is not 
> only appropriate but also timely.
> 
> presentations/discussions for the upcoming 45th NMRG meeting. That 
> includes, for example:
> 
> Please contribute and feel free to distribute this call to other 
> mailing lists whose members you believe would be interested and could contribute too.
>

---

From: yanshen <[email-masked]>
Date: Tue, 19 Sep 2017 07:41:46 +0000

Dear Laurent,

Thanks for your answer. 

Yansen

> From: Ciavaglia, Laurent (Nokia - FR/Nozay)
> [mailto:[email-masked]]
> Sent: Tuesday, September 19, 2017 3:34 PM
> To: yanshen <[email-masked]>; Sheng Jiang <[email-masked]>;
> [email-masked]
> Subject: RE: Applying AI into network management//FW: [nmrg] 45th NMRG
> 		Track:
> https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html
> 		Abstract: 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.
> 
>     2.2 QoS Management
> 		Track:
> https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html
> 		Abstract: Use multiple paths to distribute the traffic flows. Adjust the
> percentages. Avoid congestion and ensure QoS.
> 
> 		Track:
> https://www.ietf.org/mail-archive/web/idnet/current/msg00133.html
> 		Abstract: 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.)
> 
> 	2.4 QoE Management
> 		Track:
> https://www.ietf.org/mail-archive/web/idnet/current/msg00137.html
> 		Abstract: 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.
> 
> 		Track: [Jerome]
> https://www.ietf.org/mail-archive/web/idnet/current/msg00141.html ;
> [Min-Suk Kim]
> https://www.ietf.org/mail-archive/web/idnet/current/msg00153.html
> 		Abstract:
> 			[Jerome] 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 traffic with the
> underlying application assuming that the granularity of classification may vary
> (type of application, exact application name, version...)
> 			[Min-Suk Kim]continuously collect packet data, then applying
> learning process for traffic classification with generating application using deep
> learning models such as CNN (convolutional neural network) and RNN
> (recurrent neural network). Data-set to apply into the models are generated by
> precessing with features of information from flow in packet data.
> 
> 	2.6 Anomaly Detection
> 		Track:
> https://www.ietf.org/mail-archive/web/idnet/current/msg00186.html
> 		Abstract:
> 			[Jerome] 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 traffic with the
> underlying application assuming that the granularity of classification may vary
> (type of application, exact application name, version...)
> 			[Min-Suk Kim]continuously collect packet data, then applying
> learning process for traffic classification with generating application using deep
> learning models such as CNN (convolutional neural network) and RNN
> (recurrent neural network). Data-set to apply into the models are generated by
> precessing with features of information from flow in packet data.
> 
> 3. Data Focus
>     3.1 Data attribute
>     3.2 Data format
>     3.3 TBD
> 
> 4. Support Technologies
> 		Track:
> https://www.ietf.org/mail-archive/web/idnet/current/msg00146.html
> 		Abstract: A proper benchmarking framework comprises a set of
> reference procedures, methods, and models that can (or better *must*) be
> followed to assess the quality of an AI mechanism proposed to be applied to
> the network management/control area. Moreover, and much more specific to
> the IDNET topics, is the inclusion, dependency, or just the general relation of a
> standard format enforced to the data that is used (input) and produced (output)
> by the framework, so a kind of "data market" can arise without requiring to
> transform the data. The initial scope of input/output data would be the
> datasets, but also the new knowledge items that are stated as a result of
> applying the benchmarking procedures defined by the framework, which can be
> collected together to build a database of benchmark results, or just contrasted
> with other existing entries in the database to know the position of the solution
> just evaluated. This increases the usefulness of IDNET.
> 
>     4.2 TBD
>

---

From: Albert Cabellos <[email-masked]>
Date: Wed, 20 Sep 2017 22:00:28 +0900

Hi all

We have been working on using a deep-reinforcement learning agent to
automatically achieve optimal routing configuration. We demonstrate the
efficiency of the agent by means of simulations, we will soon (2 weeks
aprox) make the results public.

The results might be interesting for the IDNET community at large since, at
the best of our knowledge, this is the first use of deep-reinforcement
learning for route optimization.

In addition to this, the agent uses a reward function that must be set by
the operator. This function describes in mathematical terms the desired
state of the network, for instance to load-balance traffic among the links.
The agent then aims to maximize the reward function.

This function actually represents the policy set by the orchestrator. In my
honest opinion there is an interesting discussion on how to express such
functions in terms of management policy, this might be relevant for the
NMRG community.

Albert

On Tue, Sep 19, 2017 at 4:34 PM, Ciavaglia, Laurent (Nokia - FR/Nozay) <
[email-masked]> wrote:

>                 Abstract: 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.
>
>     2.2 QoS Management
>                 Abstract: Use multiple paths to distribute the traffic
> flows. Adjust the percentages. Avoid congestion and ensure QoS.
>
>                 Abstract: 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.)
>
>         2.4 QoE Management
>                 Abstract: 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.
>
>                 Track: [Jerome] https://www.ietf.org/mail-
> archive/web/idnet/current/msg00141.html ; [Min-Suk Kim]
>                         [Jerome] 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
> traffic with the underlying application assuming that the granularity of
> classification may vary (type of application, exact application name,
> version...)
>                         [Min-Suk Kim]continuously collect packet data,
> then applying learning process for traffic classification with generating
> application using deep learning models such as CNN (convolutional neural
> network) and RNN (recurrent neural network). Data-set to apply into the
> models are generated by precessing with features of information from flow
> in packet data.
>
>         2.6 Anomaly Detection
>                         [Jerome] 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
> traffic with the underlying application assuming that the granularity of
> classification may vary (type of application, exact application name,
> version...)
>                         [Min-Suk Kim]continuously collect packet data,
> then applying learning process for traffic classification with generating
> application using deep learning models such as CNN (convolutional neural
> network) and RNN (recurrent neural network). Data-set to apply into the
> models are generated by precessing with features of information from flow
> in packet data.
>
> 3. Data Focus
>     3.1 Data attribute
>     3.2 Data format
>     3.3 TBD
>
> 4. Support Technologies
>                 Abstract: A proper benchmarking framework comprises a set
> of reference procedures, methods, and models that can (or better *must*) be
> the IDNET topics, is the inclusion, dependency, or just the general
> relation of a standard format enforced to the data that is used (input) and
> produced (output) by the framework, so a kind of "data market" can arise
> without requiring to transform the data. The initial scope of input/output
> data would be the datasets, but also the new knowledge items that are
> stated as a result of applying the benchmarking procedures defined by the
> framework, which can be collected together to build a database of benchmark
> results, or just contrasted with other existing entries in the database to
> know the position of the solution just evaluated. This increases the
> usefulness of IDNET.
>
>     4.2 TBD
>

---

From: Alex Galis <[email-masked]>
Date: Wed, 20 Sep 2017 14:21:45 +0100

Hi All

Re: deep learning survey and tutorial http://web.cse.ohio-state.edu/~panda.2/hoti17-dl.pdf <http://web.cse.ohio-state.edu/~panda.2/hoti17-dl.pdf>

You may be interested in the deep learning survey and tutorial presented recently at Interconnects ’2017
Best Regards

Alex

> On 20 Sep 2017, at 14:00, Albert Cabellos <[email-masked]> wrote:
> 
> Hi all
> 
> We have been working on using a deep-reinforcement learning agent to automatically achieve optimal routing configuration. We demonstrate the efficiency of the agent by means of simulations, we will soon (2 weeks aprox) make the results public.
> 
> The results might be interesting for the IDNET community at large since, at the best of our knowledge, this is the first use of deep-reinforcement learning for route optimization.
> 
> In addition to this, the agent uses a reward function that must be set by the operator. This function describes in mathematical terms the desired state of the network, for instance to load-balance traffic among the links. The agent then aims to maximize the reward function.
> 
> This function actually represents the policy set by the orchestrator. In my honest opinion there is an interesting discussion on how to express such functions in terms of management policy, this might be relevant for the NMRG community.
> 
> Albert
> 
> 
> On Tue, Sep 19, 2017 at 4:34 PM, Ciavaglia, Laurent (Nokia - FR/Nozay) <[email-masked] <mailto:[email-masked]>> wrote:
> Dear Yansen, all,
> 
> From: IDNET [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of yanshen
> To: Sheng Jiang <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>                 Proposed by: [email-masked] <mailto:[email-masked]>
>                 Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html <https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html>
>                 Proposed by: [email-masked] <mailto:[email-masked]>
>                 Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html <https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html>
>                 Proposed by: [email-masked] <mailto:[email-masked]>
>                 Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00133.html <https://www.ietf.org/mail-archive/web/idnet/current/msg00133.html>
>                 Proposed by: [email-masked] <mailto:[email-masked]>
>                 Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00137.html <https://www.ietf.org/mail-archive/web/idnet/current/msg00137.html>
>                 Proposed by: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>                 Track: [Jerome] https://www.ietf.org/mail-archive/web/idnet/current/msg00141.html <https://www.ietf.org/mail-archive/web/idnet/current/msg00141.html> ; [Min-Suk Kim] https://www.ietf.org/mail-archive/web/idnet/current/msg00153.html <https://www.ietf.org/mail-archive/web/idnet/current/msg00153.html>
>                 Abstract:
>                 Proposed by: [email-masked] <mailto:[email-masked]>
>                 Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00186.html <https://www.ietf.org/mail-archive/web/idnet/current/msg00186.html>
>                 Abstract:
>                 Proposed by: [email-masked] <mailto:[email-masked]>
>                 Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00146.html <https://www.ietf.org/mail-archive/web/idnet/current/msg00146.html>
> > From: IDNET [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Sheng Jiang
> > To: [email-masked] <mailto:[email-masked]>
> > From: nmrg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Lisandro
> > Zambenedetti Granville
> > To: [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>
> > https://www.irtf.org/mailman/listinfo/nmrg <https://www.irtf.org/mailman/listinfo/nmrg>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/idnet <https://www.ietf.org/mailman/listinfo/idnet>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idnet <https://www.ietf.org/mailman/listinfo/idnet>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idnet <https://www.ietf.org/mailman/listinfo/idnet>
>

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 21 Sep 2017 10:08:27 +0000

Hi, Albert,

Thanks for your volunteer & contribution. Your presentations have been counted in. We would work out a agenda before the end of this month.

Best regards,

Sheng

From: Albert Cabellos [mailto:[email-masked]]
Sent: Wednesday, September 20, 2017 9:00 PM
To: Ciavaglia, Laurent (Nokia - FR/Nozay)
Cc: yanshen; Sheng Jiang; [email-masked]
Subject: Re: [Idnet] Applying AI into network management//FW: [nmrg] 45th NMRG meeting: Call for Contributions

Hi all

Albert

On Tue, Sep 19, 2017 at 4:34 PM, Ciavaglia, Laurent (Nokia - FR/Nozay) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Yansen, all,

Thanks, Laurent.

-----Original Message-----
From: IDNET [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of yanshen
Sent: Tuesday, September 19, 2017 8:48 AM
To: Sheng Jiang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idnet] Applying AI into network management//FW: [nmrg] 45th NMRG meeting: Call for Contributions

Hi Sheng,

Yansen

                Proposed by: [email-masked]<mailto:[email-masked]>

    2.2 QoS Management
                Proposed by: [email-masked]<mailto:[email-masked]>
                Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00131.html
                Abstract: Use multiple paths to distribute the traffic flows. Adjust the percentages. Avoid congestion and ensure QoS.

    2.3 Application (and/or DDoS) detection
                Proposed by: [email-masked]<mailto:[email-masked]>
                Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00133.html
                Abstract: 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.)

        2.4 QoE Management
                Proposed by: [email-masked]<mailto:[email-masked]>
                Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00137.html
                Abstract: 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.

                Proposed by: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

        2.6 Anomaly Detection
                Proposed by: [email-masked]<mailto:[email-masked]>
                Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00186.html
                Abstract:
                        [Jerome] 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 traffic with the underlying application assuming that the granularity of classification may vary (type of application, exact application name, version...)
                        [Min-Suk Kim]continuously collect packet data, then applying learning process for traffic classification with generating application using deep learning models such as CNN (convolutional neural network) and RNN (recurrent neural network). Data-set to apply into the models are generated by precessing with features of information from flow in packet data.

3. Data Focus
    3.1 Data attribute
    3.2 Data format
    3.3 TBD

4. Support Technologies
    4.1 Benchmarking Framework
                Proposed by: [email-masked]<mailto:[email-masked]>
                Track: https://www.ietf.org/mail-archive/web/idnet/current/msg00146.html
                Abstract: A proper benchmarking framework comprises a set of reference procedures, methods, and models that can (or better *must*) be followed to assess the quality of an AI mechanism proposed to be applied to the network management/control area. Moreover, and much more specific to the IDNET topics, is the inclusion, dependency, or just the general relation of a standard format enforced to the data that is used (input) and produced (output) by the framework, so a kind of "data market" can arise without requiring to transform the data. The initial scope of input/output data would be the datasets, but also the new knowledge items that are stated as a result of applying the benchmarking procedures defined by the framework, which can be collected together to build a database of benchmark results, or just contrasted with other existing entries in the database to know the position of the solution just evaluated. This increases the usefulness of IDNET.

    4.2 TBD

> From: IDNET [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Sheng Jiang
> To: [email-masked]<mailto:[email-masked]>
> From: nmrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lisandro
> Zambenedetti Granville
> To: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
IDNET mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idnet

_______________________________________________
IDNET mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idnet