Subject: Re: [Nmlrg] Call for comments - 2016 NMLRG activities

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 12 Jan 2016 03:58:29 +0000

Hi Sheng,

>-----Original Message-----
>From: Sheng Jiang
>Sent: Monday, January 11, 2016 11:02 AM
>To: [email-masked]
>Cc: Susan Hares; 'Jérôme François'; 'Rudra Saha'; 'Panagiotis 
>Demestichas'; 'Albert Cabellos'; 'Brian Carpenter'; 'Dacheng Zhang'
>Subject: Call for comments - 2016 NMLRG activities
>
>Hi, all NMLRG,
>
>Happy New Year! The below lists our potential 2016 NMLRG activities, 
>which have been discussed within the NMLRG organizing team. We would 
>like to hear your opinions and suggestions.
>
>NMLRG2 meeting within IETF 95 in Argentina;
>NMLRG3 interim meeting companying with an academic conference;
>NMLRG4 meeting within IETF 96 in Germany;
>NMLRG5 interim meeting companying with an academic conference;
>NMLRG6 meeting within IETF 97 in South Korea.

[Bing] The arrangement looks very active. Especially for the academic interim meetings, I believe this will engage more research people to join in NMLRG work. 
But at the same time I concern a bit about the tight agenda, do we really have plenty of content to fill the 5 meetings in one year? I don't doubt the potential wide areas of NMLRG, but considering we're at the initial stage, I just a bit worry about whether we could collect enough work within a short term..

Btw, does the organizing team consider using different policies to leverage the discussion in IETF/IRTF meetings and interim academic meetings respectively?
They are two distinguished groups, so I think different policies might be necessary. Taking the following network traffic topic as an example: in IETF/IRTF, we focus on use case collection/discussion of various aspects of traffic as you mentioned. While in interim meetings, we might organize the discussion in a different way. E.g., for prediction, there might be common principle among traffic prediction, fault prediction and other predictions in ML perspective (recognition, classification are under the same consideration) . We could invite the ML experts to talk about ML technique/algorithm selection/optimization for these different common usage. (This is only a rough idea acting as an example, might not be reasonable suggestion.)

>Firstly, we are thinking to scheme NMLRG2 meeting in IETF 95 as network 
>traffic with machine learning. It could include traffic prediction 
>using ML, traffic recognition (may even with encryption) using ML, 
>traffic classification, traffic management using ML, deploying service 
>using ML according to traffic history, etc. How do you think? Will you 
>be interested in discussion of this scheme? Will you potentially make presentations regarding it?

[Bing] I think it's a good approach that we begin to focus on some specific schemes. And network traffic is for sure a good topic in my mind.

>Secondly, for NMLRG3, ICML http://icml.cc, and EuCNC, 
>http://www.eucnc.eu/ are both very good candidates. We need to make 
>choice between them. For now, we are slightly preferring ICML, because 
>it is more ML-oriented. Giving that most of us are from network side, 
>we would like to catch more experts from Machine Learning background. 
>How do you think?
[Bing] As said above, I believe it's a good way.

>Thirdly, any suggestion for future scheme?
[Bing] The above mentioned traffic prediction, traffic recognition, traffic classification are mostly some "triggers/conditions" for subsequent actions. ML should be a proper tool to identify these triggers.
You also mentioned "traffic management" and "deploying service according to traffic history", which are just the subsequent actions. I think the logic of these actions are different with the "triggers", and they need to be more specific (E.g., traffic management might refer to routing path changing?). So, maybe in NMLRG2, we just focus on "triggers", and discuss the ML-based action decision in the future.

Best regards,
Bing

>Fourthly, for NMLRG5, we should choose the opposite location of NMLRG 
>between north American and Europe, with Asia as backup.
>
>We would like to hear comments on the above activities. It would help 
>us to better organize our meeting and we all have a good society to 
>discuss network machine learning.
>
>Many thanks and best regards,
>
>Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 13 Jan 2016 09:33:07 +0000

Hi, Bing,

Thanks for your email. My replies in lines.

>[Bing] The arrangement looks very active. Especially for the academic interim
>meetings, I believe this will engage more research people to join in NMLRG
>work.
>But at the same time I concern a bit about the tight agenda, do we really have
>plenty of content to fill the 5 meetings in one year? I don't doubt the potential
>wide areas of NMLRG, but considering we're at the initial stage, I just a bit
>worry about whether we could collect enough work within a short term..

Your concern is also mine, too. The above is an initial plan. If we do not have enough participant/presentations, we may adjust our plan. On another side, if the society does not show enough interests or motivation within a year period, we may not be able to transform this research group from proposed to a formal one.

>Btw, does the organizing team consider using different policies to leverage
>the discussion in IETF/IRTF meetings and interim academic meetings
>respectively?
>They are two distinguished groups, so I think different policies might be
>necessary. Taking the following network traffic topic as an example: in
>IETF/IRTF, we focus on use case collection/discussion of various aspects of
>traffic as you mentioned. While in interim meetings, we might organize the
>discussion in a different way. E.g., for prediction, there might be common
>principle among traffic prediction, fault prediction and other predictions in ML
>perspective (recognition, classification are under the same consideration) .

This actually gives more restrictions to our scheme. I prefer to not distinguish them. The participant could present from both perspectives.

>We could invite the ML experts to talk about ML technique/algorithm
>selection/optimization for these different common usage. (This is only a
>rough idea acting as an example, might not be reasonable suggestion.)

We certainly welcome ML experts to talk about ML technique/algorithm selection/optimization.

>[Bing] I think it's a good approach that we begin to focus on some specific
>schemes. And network traffic is for sure a good topic in my mind.
>
>[Bing] The above mentioned traffic prediction, traffic recognition, traffic
>classification are mostly some "triggers/conditions" for subsequent actions.
>ML should be a proper tool to identify these triggers.
>You also mentioned "traffic management" and "deploying service according
>to traffic history", which are just the subsequent actions. I think the logic of
>these actions are different with the "triggers", and they need to be more
>specific (E.g., traffic management might refer to routing path changing?). So,
>maybe in NMLRG2, we just focus on "triggers", and discuss the ML-based
>action decision in the future.

Yes, the two are distinguish from each other. If needed, we could organize them into sub-group in the meeting. But for the meeting organizing, I don't want to set any further restrictions along with scheme, the same as the above.

Best regards,

Sheng