Re: [Coin] Fwd: The Future of P4, Revisited

hemant@mnkcg.com Thu, 18 May 2023 17:32 UTC

Return-Path: <hemant@mnkcg.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 80C51C151524 for <coin@ietfa.amsl.com>; Thu, 18 May 2023 10:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnkcg.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H0EiEvBNEkU for <coin@ietfa.amsl.com>; Thu, 18 May 2023 10:32:20 -0700 (PDT)
Received: from web50.dnchosting.com (web50.dnchosting.com [192.64.150.50]) (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 6DB17C14CE42 for <coin@irtf.org>; Thu, 18 May 2023 10:32:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mnkcg.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Lk3QPmJOGvisDVD/r6Yhaz9g/XrvUnhkTkZm3ReZVUI=; b=dzKiVbstuWgZvKh8+sD6/jQqSY FTPEswZn269ygt5lm/5L2MvUgQ1gWOaA+8Fv9S+cQV+8KM8RVapvxooUmBOp+rrXoNV1USQbOjvGY Yw2MCQJJuUNQ2SsVdQzPRLFuAp5ouF1wzUx1e+IX0KhZAJ5UOQb5l/SZElzdUcEqNkaYtvrNWz25Q OGEf7aRfgeRq7SZOEl98g2cfI1PdKogt9sc1eWkxEbOqHdc1/mLE6uBz3E2QhS61KaTtPvIZa/tYV IKoOfbNC0JftMSI+LDzn6znsP3nUMqpnF9T2z9ImCG4PileaSFmqURkePxa9VFIhwDIDNqRbI9nPW u8rHLt2g==;
Received: from [76.191.34.66] (port=53933 helo=hemantPC) by web50.dnchosting.com with esmtpa (Exim 4.96) (envelope-from <hemant@mnkcg.com>) id 1pzhUB-000724-04; Thu, 18 May 2023 13:32:19 -0400
From: hemant@mnkcg.com
To: 'Haoyu Song' <haoyu.song@futurewei.com>, 'Hesham ElBakoury' <helbakoury@gmail.com>
Cc: ehalep@mojatatu.com, 'Toerless Eckert' <tte@cs.fau.de>, "'Bernier, Daniel'" <daniel.bernier@bell.ca>, 'Marie-Jose Montpetit' <marie@mjmontpetit.com>, 'coin' <coin@irtf.org>, 'coinrg-chairs' <coinrg-chairs@ietf.org>
References: <CAPjWiCT2ipu=yiZFr8hBGF2wy-Y_Dmze=8j+PgeDFyN7KNZR6w@mail.gmail.com> <ZGJl+6YPQarlDSTr@faui48e.informatik.uni-erlangen.de> <034201d98757$bbd87550$33895ff0$@mnkcg.com> <c98c172c-a483-5f69-9bff-dedd4b6a78bb@gmail.com> <044101d9876a$9f0490e0$dd0db2a0$@mnkcg.com> <c9b9a119-27ba-88db-2f08-18e8ff2c6337@gmail.com> <ZGQbyzRW5d1vkgVV@faui48e.informatik.uni-erlangen.de> <9EABD595-552E-4775-B69C-72BE49BD5C93@bell.ca> <00c501d988ea$bbd16f50$33744df0$@mnkcg.com> <095d01d98914$0bba99f0$232fcdd0$@mojatatu.com> <ZGWFQRGI0hmc3g5O@faui48e.informatik.uni-erlangen.de> <001101d989a0$4e180530$ea480f90$@mojatatu.com> <BY3PR13MB47877D31EC3B4511C8095D329A7F9@BY3PR13MB4787.namprd13.prod.outlook.com> <CAFvDQ9ogV5f-Nh9faKxANXV=ORHJVQQPjUH5qAAJb9uvP0KGMA@mail.gmail.com> <BY3PR13MB47876236862ABECD69BF97679A7F9@BY3PR13MB4787.namprd13.prod.outlook.com>
In-Reply-To: <BY3PR13MB47876236862ABECD69BF97679A7F9@BY3PR13MB4787.namprd13.prod.outlook.com>
Date: Thu, 18 May 2023 13:32:19 -0400
Message-ID: <033d01d989ae$b2a828a0$17f879e0$@mnkcg.com>
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIxBKBzfrzN0AW7R0uxmgt8NzLx7gE7vxklAjW3P5gCJVowzwG6owZPAbklKiwBjPTNRAHuP0tRAq/Fk7oBMBPHnALP0N6QAji6kzgB08G1vAMoLp/pAnleMoetyjaLkA==
Content-Language: en-us
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0333_01D9898D.2822E5B0"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web50.dnchosting.com
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - mnkcg.com
X-Get-Message-Sender-Via: web50.dnchosting.com: authenticated_id: hemant@mnkcg.com
X-Authenticated-Sender: web50.dnchosting.com: hemant@mnkcg.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/0h19dX-J-xUB22XFwn7pKn0Ce3k>
Subject: Re: [Coin] Fwd: The Future of P4, Revisited
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.39
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: Thu, 18 May 2023 17:32:24 -0000

It is best if such discussions take place in p4-dev mailer. How do you think TCP connection state in maintained without writing table entry by dataplane?  I wrote some of this code in the P4 compiler.

 

Hemant

 

From: Haoyu Song <haoyu.song@futurewei.com> 
Sent: Thursday, May 18, 2023 1:16 PM
To: Hesham ElBakoury <helbakoury@gmail.com>
Cc: ehalep@mojatatu.com; Toerless Eckert <tte@cs.fau.de>; hemant=40mnkcg.com@dmarc.ietf.org <hemant@mnkcg.com>; Bernier, Daniel <daniel.bernier@bell.ca>; Marie-Jose Montpetit <marie@mjmontpetit.com>; coin <coin@irtf.org>; coinrg-chairs <coinrg-chairs@ietf.org>
Subject: RE: [Coin] Fwd: The Future of P4, Revisited

 

Hi Hesham,

 

I said “it’s very limited”. P4 table is only readable (i.e., not writable) by dataplane, so it basically eliminates any dataplane stateful function that need to use tables. The stateful function can only use register arrays but unfortunately registers are local to a pipeline stage so the state update logic must be very simple and can be finish in a single stage. What you said “event” must be something very simple. Use case such as stateful load balancer can’t be implemented by P4.

 

There are some works addressing the issue. FlowBlaze is the most recent one, which needs a new chip architecture but it is still limited to simple stateful functions which can be realized in a single pipeline stage. 

 

Haoyu

 

From: Hesham ElBakoury <helbakoury@gmail.com <mailto:helbakoury@gmail.com> > 
Sent: Thursday, May 18, 2023 10:00 AM
To: Haoyu Song <haoyu.song@futurewei.com <mailto:haoyu.song@futurewei.com> >
Cc: ehalep@mojatatu.com <mailto:ehalep@mojatatu.com> ; Toerless Eckert <tte@cs.fau.de <mailto:tte@cs.fau.de> >; hemant=40mnkcg.com@dmarc.ietf.org <mailto:hemant=40mnkcg.com@dmarc.ietf.org> ; Bernier, Daniel <daniel.bernier@bell.ca <mailto:daniel.bernier@bell.ca> >; Marie-Jose Montpetit <marie@mjmontpetit.com <mailto:marie@mjmontpetit.com> >; coin <coin@irtf.org <mailto:coin@irtf.org> >; coinrg-chairs <coinrg-chairs@ietf.org <mailto:coinrg-chairs@ietf.org> >
Subject: Re: [Coin] Fwd: The Future of P4, Revisited

 

Hi Haoyu,

You say: "P4 has very limited support for stateful processing"

 

I am not sure I can agree with your characterization of P4. Perhaps can you elaborate on this.

 

Thanks

Hesham

 

On Thu, May 18, 2023, 9:19 AM Haoyu Song <haoyu.song@futurewei.com <mailto:haoyu.song@futurewei.com> > wrote:

Interesting discussion. See my comments below  [HS]

Haoyu

> For example, in the multicast drafts i write, we use C-pseudocode
> to specify behavior, but we do attempt to implemnt on Tofino in P4. Should we really
> use P4 code for the RFC specs... ? (much longer than C Pseudocode). Aka: quite selfish
> (but IETF relevant ;-) reason to highlight this point.

[EH]: This is an area I'm very interested in. Having a standardized and formal language to describe protocols and behavior can bring a lot of functionality and benefits to the IETF. 
My initial thinking is that having such a blueprint, the IETF could generate tools to create a reference implementation that can be used for interoperability purposes therefore decreasing time to test and implement protocols and therefore RFC publications.

[HS] P4 can only describe dataplane behaviors, so any control plane stuff is out of scope. For dataplane, if it's used to describe header format, it's not better than the "struct" in C. The language uses the match-action table abstraction with an implication of pipeline implementation which may make it cumbersome or even impossible to describe the  behavior (e.g.,  P4 has very limited support for stateful processing). In general, I don't think P4 at its current form can undertake the role for formal protocol specification.