Re: [Idnet] Intelligence-Defined Network Architecture and Call for Interests

Jérôme François <jerome.francois@inria.fr> Tue, 28 March 2017 18:46 UTC

Return-Path: <jerome.francois@inria.fr>
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 3D7DD1299F7 for <idnet@ietfa.amsl.com>; Tue, 28 Mar 2017 11:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 H2DDGxfMCWYX for <idnet@ietfa.amsl.com>; Tue, 28 Mar 2017 11:46:49 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9201270FC for <idnet@ietf.org>; Tue, 28 Mar 2017 11:46:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.36,237,1486422000"; d="scan'208";a="218387763"
Received: from dhcp-8907.meeting.ietf.org (HELO [31.133.139.7]) ([31.133.139.7]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 28 Mar 2017 20:46:46 +0200
To: idnet@ietf.org
References: <5D36713D8A4E7348A7E10DF7437A4B927CD15A18@NKGEML515-MBS.china.huawei.com> <CAHiKxWgT3hKr2VwhbfpmR_siHgiY4PbiKy3QgesG7uqUTnedmw@mail.gmail.com> <20170328182530.GP4808@spectre>
From: Jérôme François <jerome.francois@inria.fr>
Message-ID: <84ff06ac-61e7-3e71-f6f9-c78335c69aaf@inria.fr>
Date: Tue, 28 Mar 2017 20:46:44 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170328182530.GP4808@spectre>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/UgkrKp7cxv6LcnZk6Xq2Gz1pG70>
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\) " <idnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idnet>, <mailto:idnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idnet/>
List-Post: <mailto:idnet@ietf.org>
List-Help: <mailto:idnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idnet>, <mailto:idnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 18:46:51 -0000

Hi

Le 28/03/2017 à 20:25, Pedro Martinez-Julia a écrit :
> On Tue, Mar 28, 2017 at 10:59:38AM -0700, David Meyer 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 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 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).
> Dear Dave,
>
> You are true in that ML/domain knowledge is necessary but, however it is
> worth to take into account that it is not strictly required and it will
> even be counterproductive in some (or maybe most) situations. At the end
> of the day, encouraging (or forcing) a network expert to learn ML is
> quite difficult, the results will be delayed until the learning phase
> ends, and (most probably) s/he will never get a better solution than a
> person that has been an expert in ML from a long time ago. Therefore, it
> is better to make separate experts (in ML and the domain itself) to
> collaborate in a common solution. Therefore, and I think it has been
> mentioned before, we have to (try to) enroll experts in ML to the IDNET
> group and see what can we do together...
This is a general trend that only a single person cannot be expert in
everything. Actually, a good network expert may require good ML but also
good software skills (including software formal verification knowledge).
So, in my opinion the problem is larger.

Enhancing collaboration between network and ML expert is a path that
starts in many company and insitutes I think. Discussing with ML
experts, they are usually open and happy to discover new "use cases" 
but their first question will be "do you have some labelled datasets
that we can work with" which relates to the problem raised in previous
emails about open datasets.

In my opinion, if we wan to attract ML experts in our dicussions, we
should identify few scenrios, defined them precisely and provide an open
dataset. By defining them, I mean we have to give them all background
they need to understand (that can be built incrementally through
discussion) in a well-documented format.

jerome

>> Perhaps a useful exercise would be to write an ID that makes your
>> assumptions explicit?
>>
>> Thanks,
>> Dave
> Regards,
> Pedro
>