[Coin] 答复: Draft minutes - COINRG interim meeting - 2019-06-07

"Hejianfei (Jeffrey)" <jeffrey.he@huawei.com> Mon, 17 June 2019 02:23 UTC

Return-Path: <jeffrey.he@huawei.com>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1A0120116 for <coin@ietfa.amsl.com>; Sun, 16 Jun 2019 19:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 AjkeOFYt8Ffa for <coin@ietfa.amsl.com>; Sun, 16 Jun 2019 19:23:21 -0700 (PDT)
Received: from huawei.com (szxga01-in.huawei.com [45.249.212.187]) (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 7A931120110 for <coin@irtf.org>; Sun, 16 Jun 2019 19:23:20 -0700 (PDT)
Received: from DGGEML402-HUB.china.huawei.com (unknown [172.30.72.56]) by Forcepoint Email with ESMTP id 38E74B9F543B60DBE216; Mon, 17 Jun 2019 10:23:16 +0800 (CST)
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by DGGEML402-HUB.china.huawei.com (10.3.17.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 17 Jun 2019 10:23:15 +0800
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.87]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0439.000; Mon, 17 Jun 2019 10:23:15 +0800
From: "Hejianfei (Jeffrey)" <jeffrey.he@huawei.com>
To: Marie-Jose Montpetit <marie@mjmontpetit.com>, "hemant@mnkcg.com" <hemant@mnkcg.com>
CC: "Schooler, Eve M" <eve.m.schooler@intel.com>, "coin@irtf.org" <coin@irtf.org>
Thread-Topic: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07
Thread-Index: AdUigai2rZNEYHYLQM69gHgFkutzuv//8DOAgAAEdID/+6I1wA==
Date: Mon, 17 Jun 2019 02:23:14 +0000
Message-ID: <AB07990D3CAE53419132AB701C45693CD7A66485@dggeml529-mbx.china.huawei.com>
References: <1BBB5B8548ACEF4093CE0051D9EA9A6BDACCC990@ORSMSX105.amr.corp.intel.com> <024a01d522bc$d1d2d930$75788b90$@mnkcg.com> <A864AD0D-D726-4817-8274-D96DC89B725B@mjmontpetit.com>
In-Reply-To: <A864AD0D-D726-4817-8274-D96DC89B725B@mjmontpetit.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.40.78.175]
Content-Type: multipart/alternative; boundary="_000_AB07990D3CAE53419132AB701C45693CD7A66485dggeml529mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/ZCYXvS301EtrMbtSyuwIiZzArkU>
Subject: [Coin] 答复: Draft minutes - COINRG interim meeting - 2019-06-07
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2019 02:23:24 -0000

A few suggestions for the P4 hackathon in Montreal ( chair hat off):

(1)    Tool kit: I tend to agree with Hemant to use P4C compiler and bmv2 as the behavioral model for the P4 software switch.  We can generate virtual ports from Linux, connect these ports to this P4 software switch, use tools(e.g scapy + wireshark) to send and check the in/out packets of the switch to test if it works correctly. Then, every team in this hackathon only need a server or Virtual machine to run these software?

(2)    We also need some tasks for the teams to select and challenge, right? The attractive part of P4 and programmable switches to me is essentially to process packets in a “stateful”/correlated way. then, according to

1) these correlated packets are in the same flow or from different flows

2) the objective for processing is for better forwarding/transport or non traditional forwarding(e.g cache/compute),

we may have 4 quadrants:

1) single-flow processing for better forwarding: e.g FEC, re-ordering, flowlet-based load balancing etc.

2) co-flow processing for better forwarding: e.g new scheduling or AQM? (I am not sure how we can control the queue management part in the BVM2, need to check).

3) single-flow 4) co-flow processing for non-traditional forwarding function: Quite a few research projects has been listed in the draft(https://datatracker.ietf.org/doc/draft-he-coin-managed-networks/), but maybe the simplest use case is the ConvergeCast(http://www.cs.yale.edu/homes/aspnes/pinewiki/ConvergeCast.html?highlight=%28CategoryDistributedComputingNotes%29)?
My two cents,
Jianfei(Jeffrey)

发件人: Marie-Jose Montpetit [mailto:marie@mjmontpetit.com]
发送时间: 2019年6月14日 22:40
收件人: hemant@mnkcg.com
抄送: Schooler, Eve M <eve.m.schooler@intel.com>; coin@irtf.org; Hejianfei (Jeffrey) <jeffrey.he@huawei.com>
主题: Re: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07

Thanks for this.

I plan to work on the hackaton next week. I was and still am in all day meetings all week in Montreal.


mjm






On Jun 14, 2019, at 10:24 AM, <hemant@mnkcg.com<mailto:hemant@mnkcg.com>> <hemant@mnkcg.com<mailto:hemant@mnkcg.com>> wrote:


From: Coin <coin-bounces@irtf.org<mailto:coin-bounces@irtf.org>> On Behalf Of Schooler, Eve M
Sent: Friday, June 14, 2019 3:29 AM
To: coin@irtf.org<mailto:coin@irtf.org>
Cc: Schooler, Eve M <eve.m.schooler@intel.com<mailto:eve.m.schooler@intel.com>>; Marie-Jose Montpetit <marie@mjmontpetit.com<mailto:marie@mjmontpetit.com>>; Hejianfei (Jeffrey) <jeffrey.he@huawei.com<mailto:jeffrey.he@huawei.com>>
Subject: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07


P4 Hackathon
-----------------


Marc: As a marketing person, sees a hackathon as having two objectives: 1) promote ideas and 2) attract people to participate in the execution of those ideas. Could call it a hackathon focused on a programmable forwarding plane.
However, need to make it interesting, yet the technology should not be too broad. In the case of Noviflow, we’ve been developing programmable forwarding planes for 7 years. We have a lot of experienced engineers who know how to use the Barefoot development tools. Therefore the hackathon could basically use Barefoot's toolkit to do the exercises. In contrast to what was done in Boston, have a suggestion on areas for things to look into. Example: take a look at the intimate connection between forwarding plane and application and services, e.g., ask the students to accurately test the latency of services, which would be a specific target so can be delivered within the scope of 2 days. Contrary to the Boston P4 hackathon, have more of a unified environment, have experts from NoviFlow provide assistance so they can focus on the idea creation, not on the tools.

<hs> Boston hackathon, which I attended for the whole day, did have a unified environment – all of us used p4lang/p4c (open-source P4 compiler).  All of us in Boston who wrote P4 programs hit the ground running with p4lang/p4c.  Thus, even, we spent time on ideas, not tools.   We had over 19 years of data plane programming experience at Boston.  MNK Consulting (http://mnkcg.com<http://mnkcg.com/> ) with > 13 years of Cisco pxf, Cisco QFP,  Cavium Xpliant data planes, and P4 experience since Fall 1996.  Juniper was there with 6 years data plane programming.  Now, MNK Consulting has Barefoot Tofino experience as well – I am working remotely on Saturday and available for help  via the P4 Slack channel (userid: Hemant).

I see a problem with Barefoot’s Tofino tools chain.  For example, there are 20 of us at the P4 hackathon.  Each one of us would like the Tofino tools chains installed on our laptops.  How would NoviFlow help with that before the hackathon?  Or will NoviFlow provide 20 machines with Tofino tools chain built and ready for use?  Sharing machines slows down productivity.  What if some of us are remote – how do we login to the machines remotely?  I have already asked about NDA issues with Barefoot.

In contrast, if one uses the p4lang/p4c, we have no external dependency and start writing P4 programs immediately. P4lang/p4c also includes a tools chain to test using packets.   I suggest to use either environment and crank out P4 code.

We should get more ideas – please add them to the wiki: https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon

Hemant