Re: [Coin] mtpsa and P4

[[e-mail]]

Hi Radostin,

 

Thanks for the references.  I see that you are after separating user
application traffic in which case all your points are valid in the email
below.  

 

It would be good to report how many different users and user apps per user
can you support on a Tofino asic or the NetFPGA? 

 

Note, the per port queues in a switch are also a resource - such resources
do not support a per user app kind of traffic shaping.  A switch may be only
using Token bucket to schedule port queues.  Not all user resources can be
separated and also P4 does not support traffic shaping in the language.  

 

If I don't use separate pipeline, I can always separate user app traffic
using Cisco ACI which is being standardized in the IETF as we speak.
Web-scale data centers are already using only IPv6 internally.  The IPv6
address or header has enough bits to steal from to separate a user's app
traffic as well. I could also use a MPLS VRF for app id internally in the
switch. 

 

Best wishes,

 

Hemant

 

From: Radostin Stoyanov <[e-mail]> 
Sent: Tuesday, February 09, 2021 1:49 PM
To: [e-mail]; [e-mail]
Cc: Noa Zilberman <[e-mail]>
Subject: Re: [Coin] mtpsa and P4

 

Hello Hemant,

Thank you for your feedback.

In addition to VMs, cloud providers also provide fully managed container
orchestration services (Docker, Kubernetes) and serverless computing (lambda
functions). In contrast to VMs, these technologies have higher density, low
start-up times (milliseconds or seconds), and automated lifecycle
management, scaling, and orchestration. A single node in a cluster could run
workloads from many customers and using a separate virtual switch instance
for each customer could have a significant overhead. Cloud providers often
use SmartNICs (AWS Nitro, Azure SmartNICs) to offload packet processing to
specialised hardware.

MTPSA aims to address the problem of programmable data plane (PDP)
virtualization [1] as opposed to providing multiple isolated logical
networks [2]. It is still an early work and it was presented on December 1,
2020 at the 3rd P4 Workshop in Europe (EuroP4). We proposed an
implementation of a P4C compiler backend [3], BMV2 software switch target
[4] and a P4-NetFPGA prototype [5].

[1] https://ieeexplore.ieee.org/abstract/document/9078127
[2]
https://www.gta.ufrj.br/ensino/cpe717-2011/openflow-tr-2009-1-flowvisor.pdf
[3] https://github.com/mtpsa/p4c
[4] https://github.com/mtpsa/behavioral-model
[5] https://github.com/mtpsa/P4-NetFPGA-MTPSA

I hope this helps.

Best wishes,
Radostin

On 09/02/2021 16:24, hemant=[e-mail]
<mailto:hemant=[e-mail]>  wrote:

For a host, such as a user using a cloud, the cloud operator just provides a
VM per user or multiple VMs to a user.  This is why, for a host, a MTPSA
wasn't necessary.  With a network virtual switch, of course, MTPSA would
help.  However, in the same cloud, if a virtual switch is used, why not just
provide a virtual switch per user and the switch uses a few ports? This way
MTPSA is avoided.  Use a router to isolate virtual switch traffic.  If I
really want to separate user traffic, I could also use a virtual router per
user and don't use MTPSA - of course, a router has multiple interfaces to
supports connections to different VMs for a user.

 

Around May 2017, the first P4 compiler (p4c) came out as p4lang/p4c.
Hardware asic vendors have taken this p4c and developed their p4c backends.
It takes few years to develop a compiler backend.  I suspect, this is why
P4's focus could not get to MTPSA.  In the past few months, a P4 to DPDK p4c
backend was added to p4lang/p4c.   Now that server machines are running P4
to DPDK, I think, more virtual switch R&D will take place. In the past there
has been a P4 to OVS (Open Virtual Switch) but I don't know if this effort
looked into MTPSA.  

 

Also, the source code for the P4 bmv2 software switch is obtuse and hard to
change causing more delays.

 

Best wishes,

 

Hemant