From nobody Sat Apr 1 16:20:09 2017 Return-Path: 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 6972F12946A for ; Sat, 1 Apr 2017 16:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cnl.sk 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 Z2L5Lh50OPJV for ; Sat, 1 Apr 2017 16:19:54 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CAE128BB7 for ; Sat, 1 Apr 2017 16:19:53 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id s68so112003427vke.3 for ; Sat, 01 Apr 2017 16:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cnl.sk; s=googledkim; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QkZz1aSkGT13SEbJuIoBMJWFS2C+m6wbczxbLbSC0xc=; b=NLndUzrUCiNAMjyfU38G//3W8n/Yrw1SAauDdLb0UhWcsTMmLYHRQHDdjeWqxQaRmQ krdJhcKc2Yy5otnydZgB0GMsoE5SRcSVPCqWviMkYccgPe6U2tQvkQWvyK2Xiftl6xdP uivCC8WUeFjJHgCJscmzZw2v7Of8itus69QaE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QkZz1aSkGT13SEbJuIoBMJWFS2C+m6wbczxbLbSC0xc=; b=nVKrnnFD7FxVHxuJ8sNnZys4m1D/maBbvZlTRO2jGXdL36bRzs8bMDCn3VWGaSPp7l mQIknzqqB1eWZrrWLseRXFHLFTI63OAGCPNu80Mv8SaJFeKG0dhIddn2xNlyutS+AJ64 uK1kS4lOq4FQ1paUiCb4xdE01Z43lj1ChuRLTdor7jYgJYI3HzMfnd9+BtK7SBJaAh3M 28hpBcikneRVsQ7xI3GZZZrwRCMr97dDmZp01ZkkPOjwxhzfUzMr1Eqw8UITKLO9pCLD vKbzOucVb1myTrbzf+0HVZxkjwwpYm0QKdbB/dErTBQhZ11fRWi6GVF0TqiJPU0EAFK3 myZg== X-Gm-Message-State: AFeK/H38yLW+CSObtwwL+c0k7JN1SdNs16Tk9tWM/rKfsttI6T84W/bWQd3v+e4cJYl+JWubgOIzycvlYXs18w== X-Received: by 10.31.242.134 with SMTP id q128mr4795996vkh.53.1491088793002; Sat, 01 Apr 2017 16:19:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.184.7 with HTTP; Sat, 1 Apr 2017 16:19:52 -0700 (PDT) In-Reply-To: References: <3B110B81B721B940871EC78F107D848CF33029@DGGEMM506-MBS.china.huawei.com> From: Juraj Giertl Date: Sun, 2 Apr 2017 01:19:52 +0200 Message-ID: To: David Meyer Cc: "dingxiaojian (A)" , "idnet@ietf.org" , Brian E Carpenter , Sheng Jiang Content-Type: multipart/alternative; boundary=94eb2c14c6e4d5fdf8054c23295b Archived-At: Subject: Re: [Idnet] Intelligence-Defined Network Architecture and Call for Interests X-BeenThere: idnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The IDNet \(Intelligence-Defined Network\) " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 23:19:59 -0000 --94eb2c14c6e4d5fdf8054c23295b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, such an interesting reading led me to a reminiscence of my 10 years old experiments with applying some adaptive techniques to the optimization of network traffic monitoring [0],[1]. Obviously, we were struggling with the lack of data sets, thus compensated the need for traffic classification with the Kohonen's self-organizing maps resulting into a simple and rather effective solution albeit a bit tedious during its initial deployment (further research would have been necessary, but my job has changed). Now, at the "operator" side, seeing tons of packets flowing through the data center network, have no clue how to get and use them. Even though the anonymization methods are well elaborated (e.g. in [2]), the recent challenges are of another sort - cannot imagine what would need to be done for bypassing the legal obligations. All the best, Juraj [0] http://link.springer.com/article/10.1007/s10559-008-9005-0 [1] Adaptive sampling for network monitoring / Juraj Giertl [et al.], In: ISAST Transactions on Communications and Networking. Vol. 1, no. 1 (2007), p. 52-61. - ISSN 1797-0989 [2] https://datatracker.ietf.org/doc/html/rfc6235 On Fri, Mar 31, 2017 at 5:08 PM, David Meyer wrote: > I don't think there is any question that there is a problem with data > sets; as many of you know this has been one of my main points regarding > what is holding back ML for networking over the last 4 or so years. Of > course, how to solve this problem is a different question. > > However, as least I don't necessarily agree with this statement: " So my > point is data set, not ML model. We can select some existing models (SVM= , > ELM, bayes, etc) to learn different tasks. We do not research the princip= le > of ML algorithm, but use them to slove [sic] network problems", we might > check out what Andrew says while discussing what the scare resources > required to make progress in ML for any domain ([0], near the bottom): > > o Data. Among leading AI teams, many can likely replicate others=E2=80=99= software > in, at most, 1=E2=80=932 years. But it is exceedingly difficult to get ac= cess to > someone else=E2=80=99s data. Thus data, rather than software, is the defe= nsible > barrier for many businesses. > > o Talent. Simply downloading and =E2=80=9Capplying=E2=80=9D open-source s= oftware to your > data won=E2=80=99t work. AI needs to be customized to your business conte= xt and > data. This is why there is currently a war for the scarce AI talent that > can do this work. > > There is a ton of experience (and literature) reinforcing these points, > but suffice it to say that Andrew knows what he's talking about. > > In any event, it seems clear that we are all on the same page with respec= t > to the problems with data sets (again, exactly how to solve this problem = is > open). However, we seem to have a difference in our understanding of bot= h > the field is today and how we make progress. In particular, Andrew seems = to > be saying the opposite of what you say above (quoted text). My experience > tracks more with what Andrew is saying. > > Summary: We need to attack both problems. > > Dave > > [0] https://hbr.org/2016/11/what-artificial-intelligence- > can-and-cant-do-right-now > > > On Thu, Mar 30, 2017 at 6:04 PM, dingxiaojian (A) < > dingxiaojian1@huawei.com> wrote: > >> Hi Brian, >> You are right. >> I have worked in an institute more than five years. The main work >> is use ML to solve the domain problem. However, for privacy reason, it= 's >> very hard to get some real domain data sets. So the results learned by a= ny >> ML models is not reliable. >> So I think the important/first thing we do is to construct real and >> reliable data sets of network domain. Just like UCI repository ( >> https://archive.ics.uci.edu/ml/datasets.html) or images datasets ( >> https://www.cs.utah.edu/~lifeifei/datasets.html) . Only the common and >> real data sets are agreed with all we, different ML models can be applie= d >> to validate and predict. >> So my point is data set, not ML model. We can select some existing >> models (SVM, ELM, bayes, etc) to learn different tasks. We do not resear= ch >> the principle of ML algorithm, but use them to slove network problems. >> >> Best regards, >> >> Xiaojian >> >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: IDNET [mailto:idnet-bounces@ietf.org] =E4= =BB=A3=E8=A1=A8 Brian E Carpenter >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B43=E6=9C=8830=E6=97=A5= 23:37 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Sheng Jiang ; David = Meyer >> =E6=8A=84=E9=80=81: idnet@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [Idnet] Intelligence-Defined Network Architectur= e and Call for >> Interests >> >> Agreed, and there are (still) two key points: >> >> 1. What is our underlying model (what Dave called a "theory of >> networking")? With no such model, it's very hard to tell the ML system w= hat >> to do. >> >> 2. And as others have said: get hold of large datasets that can processe= d >> by ML according to that model. For developing open solutions, a corpus o= f >> open data sets seems essential. As anybody from the network measurement >> community will tell you, getting hold of large data sets from operators = is >> extremely difficult for both privacy and commercial reasons. >> >> Brian >> >> >> On 31/03/2017 03:41, Sheng Jiang wrote: >> > Hi, David, >> > >> > I think I agree with you, but in slight different expression. Yes, th= e >> hard parts of getting ML into Network lies on machine learning. But, it = is >> not that we need to develop any new ML technical/algorithms for networki= ng >> in particular. It is that we MUST re-set up our network domain knowledge >> from the perspective of applying ML. My slides [0] does not suggest that >> *someone else* will handle the ML part. Actually, oppositely, it suggest= s >> some experts who have knowledge of both ML and network (probably we) wou= ld >> develop tools/algorithms/systems to handle the ML part for other network >> experts (more than 98 percent of current network administrators). So tha= t, >> these network experts would be allowed to manage their network easily wi= th >> intelligence association, but no need to become ML experts themselves. >> Here, we would like to treat the network administrators like the users i= n >> other successful ML application. We are the domian experts to do the dir= ty >> AI work for them. >> > >> > I believe we have common understanding in the above description. But >> certainly my slides needs further refine to clarify my viewpoint. >> > >> > Best regards, >> > >> > Sheng >> > ________________________________ >> > From: IDNET [idnet-bounces@ietf.org] on behalf of David Meyer >> > [dmm@1-4-5.net] >> > Sent: 29 March 2017 2:01 >> > To: Sheng Jiang >> > Cc: idnet@ietf.org >> > Subject: Re: [Idnet] Intelligence-Defined Network Architecture and >> > Call for Interests >> > >> > s/NMRL/NMLRG/ (sorry about that). Dave >> > >> > On Tue, Mar 28, 2017 at 10:59 AM, David Meyer > dmm@1-4-5.net>> wrote: >> > Hey Sheng, >> > >> > I just wanted to revive my key concern on [0] (same one I made at the >> NMRL): The hard parts of getting Machine Learning intelligence into >> Networking is the Machine Learning part. In addition, successful deploym= ent >> of ML requires knowledge of ML combined with domain knowledge. We >> definitely have the domain knowledge; the problem is that we don't have = the >> ML knowledge, and this is one of the big factors holding us back; see e.= g. >> Andrew's discussion of talent in [1]. Slides such as [0] seem to imply >> that *someone else* (in particular, not us) will handle the ML part of = all >> of this. I'll just note that in general successful deployments of ML don= 't >> work this way; the domain experts will have to learn ML (and vice versa) >> for us to be successful (again, see [1] and many others). >> > >> > Perhaps a useful exercise would be to write an ID that makes your >> assumptions explicit? >> > >> > Thanks, >> > >> > Dave >> > >> > >> > [0] >> > https://www.ietf.org/proceedings/97/slides/slides-97-nmlrg-intelligenc >> > e-defined-network-01.pdf [1] >> > https://hbr.org/2016/11/what-artificial-intelligence-can-and-cant-do-r >> > ight-now >> > >> > >> > On Tue, Mar 28, 2017 at 9:29 AM, Sheng Jiang > > wrote: >> > Hi, all, >> > >> > Although there are many understanding for Intelligence-Defined Network= , >> we are actually using this IDN as a term reference to the SDN-beyond >> architecture that we presented in IETF97, see the below link. A referenc= e >> model is presented in page 3, while potential standardization works is >> presented in page 9. >> > >> > https://www.ietf.org/proceedings/97/slides/slides-97-nmlrg-intelligenc >> > e-defined-network-01.pdf >> > >> > Although it might be a little bit too early for AI/ML in network givin= g >> the recent story of the concluded proposed NMLRG, we still would like to >> call for interests in IDN. Anybody (on site in Chicago this week) are >> interested in this or even wider topics regarding to AI/ML in network, >> please contact me on jiangsheng@huawei.com >> . Then we may have an informal meeting to discuss some common interests = and >> potential future activities (not any activities in IETF, but also other = STO >> or experimental trails, etc.) on Thursday morning. >> > >> > FYI, we have already working on a Work Item, called IDN in the ETSI NG= P >> (Next Generation Protocol) ISG, links below. >> > >> > https://portal.etsi.org/tb.aspx?tbid=3D844&SubTB=3D844 >> > https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID= =3D >> > 51011 >> > >> > Meanwhile, please do use this mail list as a forum to discuss any >> topics that may applying AI/ML into network area. >> > >> > Best regards, >> > >> > Sheng >> > _______________________________________________ >> > 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 >> > >> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > IDNET mailing list > IDNET@ietf.org > https://www.ietf.org/mailman/listinfo/idnet > > --94eb2c14c6e4d5fdf8054c23295b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

such an interesti= ng reading led me to a reminiscence of my 10 years old experiments with applying some=20 adaptive techniques to the optimization of network traffic monitoring=20 [0],[1]. Obviously, we were struggling with the lack of data sets, thus=20 compensated the need for traffic classification with the Kohonen's self-organizing maps resulting into a simple and rather effective=20 solution albeit a bit tedious during its initial deployment (further=20 research would have been necessary, but my job has changed).

N= ow, at the "operator" side, seeing tons of packets flowing through t= he data=20 center network, have no clue how to get and use them. Even though the=20 anonymization methods are well elaborated (e.g. in [2]), the recent=20 challenges are of another sort - cannot imagine what would need to be=20 done for bypassing the legal obligations.

All the best,
Juraj


[0] http://link= .springer.com/article/10.1007/s10559-008-9005-0
[1] Adapti= ve sampling for network monitoring / Juraj Giertl [et al.], In: ISAST Transactions on Communications and Networking. Vol. 1, no. = 1 (2007), p. 52-61. - ISSN 1797-0989
[2] https://datatracker.ietf.o= rg/doc/html/rfc6235

On Fri, Mar 31, 2017 at 5:08 PM, David Meyer <dmm@1-4-= 5.net> wrote:
I don't think there is any question that there is a problem with da= ta sets; as many of you know this has been one of my main points regarding = what is holding back ML for networking over the last 4 or so years. Of cour= se, how to solve this problem is a different question.=C2=A0

=
However, as least I don't necessarily agree with this statement: &= quot;=C2=A0So my point is data set, not ML model.=C2=A0 We can select some = existing models (SVM, ELM, bayes, etc) to learn different tasks. We do not = research the principle of ML algorithm, but use them to slove [sic] network= problems", =C2=A0we might check out what Andrew says while discussing= what the scare resources required to make progress in ML for any domain ([= 0], near the bottom):

o Data. Among leading AI team= s, many can likely replicate others=E2=80=99 software in, at most, 1=E2=80= =932 years. But it is exceedingly difficult to get access to someone else= =E2=80=99s data. Thus data, rather than software, is the defensible barrier= for many businesses.

o Talent. Simply downloading= and =E2=80=9Capplying=E2=80=9D open-source software to your data won=E2=80= =99t work. AI needs to be customized to your business context and data. Thi= s is why there is currently a war for the scarce AI talent that can do this= work.

There is a ton of experience (and lite= rature) reinforcing these points, but suffice it to say that Andrew knows w= hat he's talking about.

In any event, it seems= clear that we are all on the same page with respect to the problems with d= ata sets (again, exactly how to solve this problem is open). However, =C2= =A0we seem to have a difference in our understanding of both the field is t= oday and how we make progress. In particular, Andrew seems to be saying the= opposite of what you say above (quoted text). My experience tracks more wi= th what Andrew is saying.

Summary: =C2=A0We need t= o attack both problems.=C2=A0

Dave



On Thu, Mar = 30, 2017 at 6:04 PM, dingxiaojian (A) <dingxiaojian1@huawei.com= > wrote:
Hi Brian,
=C2=A0 =C2=A0 You are right.
=C2=A0 =C2=A0 =C2=A0I have worked in an institute more than five years. The= main work is=C2=A0 use ML to solve the domain problem.=C2=A0 However, for = privacy reason, it's very hard to get some real domain data sets. So th= e results learned by any ML models is not reliable.
=C2=A0 =C2=A0 So I think the important/first thing we do is to construct re= al and reliable data sets of network domain. Just like UCI repository (https://archive.ics.uci.edu/ml/datasets.html) or im= ages datasets (https://www.cs.utah.edu/~lifeifei= /datasets.html) . Only the common and real data sets are agreed with al= l we, different ML models can be applied to validate and predict.
=C2=A0 =C2=A0So my point is data set, not ML model.=C2=A0 We can select som= e existing models (SVM, ELM, bayes, etc) to learn different tasks. We do no= t research the principle of ML algorithm, but use them to slove network pro= blems.

=C2=A0Best regards,

Xiaojian


-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: IDNET [mailto:idnet-bounces@ietf.org] =E4=BB=A3=E8= =A1=A8 Brian E Carpenter
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B43=E6=9C=8830=E6=97=A5 23= :37
=E6=94=B6=E4=BB=B6=E4=BA=BA: Sheng Jiang <jiangsheng@huawei.com>; David Meyer <= ;dmm@1-4-5.net> =E6=8A=84=E9=80=81: idn= et@ietf.org
=E4=B8=BB=E9=A2=98: Re: [Idnet] Intelligence-Defined Network Architecture a= nd Call for Interests

Agreed, and there are (still) two key points:

1. What is our underlying model (what Dave called a "theory of network= ing")? With no such model, it's very hard to tell the ML system wh= at to do.

2. And as others have said: get hold of large datasets that can processed b= y ML according to that model. For developing open solutions, a corpus of op= en data sets seems essential. As anybody from the network measurement commu= nity will tell you, getting hold of large data sets from operators is extre= mely difficult for both privacy and commercial reasons.

=C2=A0 =C2=A0Brian


On 31/03/2017 03:41, Sheng Jiang wrote:
> Hi, David,
>
> I think I agree with you, but in slight different=C2=A0 expression. Ye= s, the hard parts of getting ML into Network lies on machine learning. But,= it is not that we need to develop any new ML technical/algorithms for netw= orking in particular. It is that we MUST re-set up our network domain knowl= edge from the perspective of applying ML. My slides [0] does not suggest th= at *someone else* will handle the ML part. Actually, oppositely, it suggest= s some experts who have knowledge of both ML and network (probably we) woul= d develop tools/algorithms/systems to handle the ML part for other network = experts (more than 98 percent of current network administrators). So that, = these network experts would be allowed to manage their network easily with = intelligence association, but no need to become ML experts themselves. Here= , we would like to treat the network administrators like the users in other= successful ML application. We are the domian experts to do the dirty AI wo= rk for them.
>
> I believe we have common understanding in the above description. But c= ertainly my slides needs further refine to clarify my viewpoint.
>
> Best regards,
>
> Sheng
> ________________________________
> From: IDNET [idnet-bounces@ietf.org] on behalf of David Meyer
> [dmm@1-4-5.net]=
> Sent: 29 March 2017 2:01
> To: Sheng Jiang
> Cc: idnet@ietf.org=
> Subject: Re: [Idnet] Intelligence-Defined Network Architecture and
> Call for Interests
>
> s/NMRL/NMLRG/=C2=A0 =C2=A0(sorry about that). Dave
>
> On Tue, Mar 28, 2017 at 10:59 AM, David Meyer <dmm@1-4-5.net<mailto:dmm@1-4-5.net>> wrote: > Hey Sheng,
>
> I just wanted to revive my key concern on [0] (same one I made at the = NMRL): The hard parts of getting Machine Learning intelligence into Network= ing is the Machine Learning part. In addition, successful deployment of ML = requires knowledge of ML combined with domain knowledge. We definitely have= the domain knowledge; the problem is that we don't have the ML knowled= ge, and this is one of the big factors holding us back; see e.g. Andrew'= ;s discussion of talent in [1].=C2=A0 Slides such as [0] seem to imply that= *someone else* (in particular, not us)=C2=A0 will handle the ML part of al= l of this. I'll just note that in general successful deployments of ML = don't work this way; the domain experts will have to learn ML (and vice= versa) for us to be successful (again, see [1] and many others).
>
> Perhaps a useful exercise would be to write an ID that makes your assu= mptions explicit?
>
> Thanks,
>
> Dave
>
>
> [0]
> https://www.ietf.org/proc= eedings/97/slides/slides-97-nmlrg-intelligenc
> e-defined-network-01.pdf [1]
> https://hbr.org/2016/11/w= hat-artificial-intelligence-can-and-cant-do-r
> ight-now
>
>
> On Tue, Mar 28, 2017 at 9:29 AM, Sheng Jiang <jiangsheng@huawei.com<mailto:<= a href=3D"mailto:jiangsheng@huawei.com" target=3D"_blank">jiangsheng@h= uawei.com>> wrote:
> Hi, all,
>
> Although there are many understanding for Intelligence-Defined Network= , we are actually using this IDN as a term reference to the SDN-beyond arch= itecture that we presented in IETF97, see the below link. A reference model= is presented in page 3, while potential standardization works is presented= in page 9.
>
> https://www.ietf.org/proc= eedings/97/slides/slides-97-nmlrg-intelligenc
> e-defined-network-01.pdf
>
> Although it might be a little bit too early for AI/ML in network givin= g the recent story of the concluded proposed NMLRG, we still would like to = call for interests in IDN. Anybody (on site in Chicago this week) are inter= ested in this or even wider topics regarding to AI/ML in network, please co= ntact me on jian= gsheng@huawei.com<mailto:jiangsheng@huawei.com> . Then we may have an in= formal meeting to discuss some common interests and potential future activi= ties (not any activities in IETF, but also other STO or experimental trails= , etc.)=C2=A0 on Thursday morning.
>
> FYI, we have already working on a Work Item, called IDN in the ETSI NG= P (Next Generation Protocol) ISG, links below.
>
> https://portal.etsi.org/tb.aspx?= tbid=3D844&SubTB=3D844
> https://portal.etsi.org= /webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=3D
> 51011
>
> Meanwhile, please do use this mail list as a forum to discuss any topi= cs that may applying AI/ML into network area.
>
> Best regards,
>
> Sheng
> _______________________________________________
> IDNET mailing list
> IDNET@ietf.org= <mailto:IDNET@ietf.org>
> https://www.ietf.org/mailman/listinfo/idnet=
>
>
>
>
>
> _______________________________________________
> 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
_______________________________________________
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


--94eb2c14c6e4d5fdf8054c23295b-- From nobody Sun Apr 2 16:07:54 2017 Return-Path: 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 9CB14129441 for ; Sun, 2 Apr 2017 16:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 C9Pcj-FmXvsk for ; Sun, 2 Apr 2017 16:07:50 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 80A89126C22 for ; Sun, 2 Apr 2017 16:07:50 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id v32N7nvj088142 for ; Mon, 3 Apr 2017 08:07:49 +0900 (JST) Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by gw2.nict.go.jp with ESMTP id v32N7nXB088128 for ; Mon, 3 Apr 2017 08:07:49 +0900 (JST) Received: from spectre (unknown [133.243.115.68]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPS id 3A209A3B5 for ; Mon, 3 Apr 2017 08:07:49 +0900 (JST) Date: Mon, 3 Apr 2017 08:07:51 +0900 From: Pedro Martinez-Julia To: idnet@ietf.org Message-ID: <20170402230751.GA9812@spectre> References: <3B110B81B721B940871EC78F107D848CF33029@DGGEMM506-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Subject: Re: [Idnet] Intelligence-Defined Network Architecture and Call for Interests X-BeenThere: idnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The IDNet \(Intelligence-Defined Network\) " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 23:07:52 -0000 Hi, During one of my last side meetings last week I thought that it could be possible to ask IETF attendees to allow "us" to capture their traffic (installing sniffers in the APs and routers). If anyone knows if it is "plausible" and "possible", please let us know. Thank you. Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From g.trimponias@huawei.com Wed Apr 26 19:47:11 2017 Return-Path: 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 42016129443 for ; Wed, 26 Apr 2017 19:47:11 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 rCGuZgC55yxg for ; Wed, 26 Apr 2017 19:47:09 -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 712A01294D3 for ; Wed, 26 Apr 2017 19:47:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLV25730; Thu, 27 Apr 2017 02:47:05 +0000 (GMT) Received: from SZXEMI404-HUB.china.huawei.com (10.82.75.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 27 Apr 2017 03:47:04 +0100 Received: from SZXEMI501-MBS.china.huawei.com ([169.254.2.140]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Thu, 27 Apr 2017 10:47:00 +0800 From: Trimponias Georgios To: "idnet@ietf.org" Thread-Topic: Calll for participation - "Learning Methods for Control of Communication Networks" Thread-Index: AdK/AInox9N03HgsTV63/jgx6S0Jdg== Date: Thu, 27 Apr 2017 02:46:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.153.192] Content-Type: multipart/alternative; boundary="_000_DEA98144A94CBB4D86A91B80AC73FB9648D2481ESZXEMI501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59015BAA.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.140, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 536eb6ba5d4ffa237d8a47980fa6b701 Archived-At: X-Mailman-Approved-At: Wed, 26 Apr 2017 19:58:29 -0700 Subject: [Idnet] Calll for participation - "Learning Methods for Control of Communication Networks" X-BeenThere: idnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The IDNet \(Intelligence-Defined Network\) " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 02:54:46 -0000 --_000_DEA98144A94CBB4D86A91B80AC73FB9648D2481ESZXEMI501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Call for Participation Learning Methods for Control of Communications Networks RLDM Satellite Meeting June 14-15 2017 University of Michigan, Ann Arbor Learning methods have been successfully applied to various control problems= in communications networks for more than four decades. Nevertheless, there= has yet to be a concerted effort to systematically explore the potential p= erformance benefits to be reaped by using learning methods in this domain. = Given the continued growth in the size and dynamics of communications netwo= rks, in the number and location of communicating devices, and in the volume= of traffic to be transported and the types of applications to be supported= , the algorithms for controlling the behavior of a network should scale acc= ordingly yet do so under uncertainty about the current state of the entire = network. Learning methods hold promise for enabling large dynamic communica= tions networks to effectively, efficiently, and autonomously accommodate in= creasing and varied user demand. Communications networks also offer in retu= rn a rich experimental domain for research on learning and decision making. The goal of this meeting is to foster collaboration between the communicati= ons networks and learning communities, bringing to bear powerful learning a= lgorithms for control of communications networks and exposing a complex dom= ain for research on learning methods. We welcome submissions of original re= search describing theoretical or empirical results using learning methods f= or network control. Here, the term 'network control' encompasses decision m= aking at all time scales, ranging from processing individual packets and fl= ows to network planning and design. Learning methods that require neither a= detailed model of the network nor supervisory input to make appropriate de= cisions are of particular interest for this meeting. To participate in the meeting, you must prepare an extended abstract of at = most four pages, inclusive of figures and references, and must submit the a= bstract directly to the organizers by 12 May 2017. Abstracts will be used t= o determine the speakers and the discussion topics for the meeting. Each pa= rticipant's abstract will be made available electronically as part of the r= ecord of the meeting, provided the participant explicitly grants permission= to do so. Abstract formatting: LaTex template: rldmsubmit.sty LaTex example: rldm.tex Abstract samples: rldm.pdf, rldm.rtf Organizers: Martha Steenstrup, Stow Research L.L.C. George Trimponias, Huawei Technologies Co., Ltd. --_000_DEA98144A94CBB4D86A91B80AC73FB9648D2481ESZXEMI501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Call for Participation

Learning Methods for Control of Communications= Networks

RLDM Satellite Meeting

June 14-15 2017

University of Michigan, Ann Arbor

 

Learning methods have been successfully applied to various con= trol problems in communications networks for more than four decades. Nevertheless, there has yet to be a concerted effort to systemati= cally explore the potential performance benefits to be reaped by using lear= ning methods in this domain. Given the continued growth in the size and dyn= amics of communications networks, in the number and location of communicating devices, and in the volume of = traffic to be transported and the types of applications to be supported, th= e algorithms for controlling the behavior of a network should scale accordi= ngly yet do so under uncertainty about the current state of the entire network. Learning methods hold promi= se for enabling large dynamic communications networks to effectively, effic= iently, and autonomously accommodate increasing and varied user demand. Com= munications networks also offer in return a rich experimental domain for research on learning and decision= making.

 

The goal of this meeting is to foster collaboration between the communi= cations networks and learning communities, bringing to bear powerful learni= ng algorithms for control of communications networks and exposing a complex domain for research on learning methods. W= e welcome submissions of original research describing theoretical or empiri= cal results using learning methods for network control. Here, the term ‘network control’ encompasse= s decision making at all time scales, ranging from processing individual pa= ckets and flows to network planning and design. Learning methods that require neither a detailed model of the network nor = supervisory input to make appropriate decisions are of particular interest = for this meeting.

 

To participate in the meeting, you must prepare an extended abstract of= at most four pages, inclusive of figures and references, and must submit t= he abstract directly to the organizers by 12 May 2017. Abstracts will be used to determine the speakers and the discuss= ion topics for the meeting. Each participant’s abstract will be made available electronically as part of the record = of the meeting, provided the participant explicitly grants permission to do so.

 

Abstract formatting:

LaTex template: rldmsubmit.sty

LaTex example: rldm.tex

Abstract samples: rldm.pdf, rldm.rtf=

 

Organizers:<= /span>

Martha Steenstrup, Stow Research L.L.C.

George Trimponias, Huawei Technologies Co., Ltd.=

 

--_000_DEA98144A94CBB4D86A91B80AC73FB9648D2481ESZXEMI501MBSchi_--