Re: [Coin] [arch-d] [icnrg] recasting address semantics

[Toerless Eckert <[e-mail]>]

Jeff, *:

It would be lovely to capture these aspects so we do not need to restart
the discussion from 0 every time. Not sure, how feasible it is to get
actual market data though. Of course, not every forwarding feature needs
to go onto every hop as well. Cc'ing [e-mail] because maybe there
are more folks interested in co-writing such an informational document.

I am not sure if barefoot was/is necessarily more expensive at the chip
level than other data center switch chips, or whether it is even a lot
more programmable. Comparing a challenger with a new sales model of
"programmability" with big incumbants that primarily operate on "best price"
is quite difficult. And obviously, the very big customers may be happy
about programmable platforms for experimentation/development, but once they
have figured out exactly what they want, they will go for cost optimiation.

As i think i said: Selling the differential for a programmable forwarding
plane requires new services such as programmable slices. Or dedicated R&D
/ repurposavbe network equipment.  There is a reason why we do not have it
for existing business/services.

Vendor-internal reprogrammability has btw. been tried a few times in my
experience. FPGA for example for PTP, deterministic ethernet, video monitoring
just to name a few. But unless its user-programmable its a very difficult
decision to put such programmability into equipment at all. 

Cheers
    Toerless

On Sun, Feb 27, 2022 at 01:38:58PM -0800, Jeff Tantsura wrote:
> I’d think - we need to differentiate between run time and repurposing, run time  programmability comes at cost, lower speed, higher power consumption, one need to clearly understand trade-offs and what to optimize towards, if an IP packet needs to be moved from port A to port B without any significant changes to its processing (checksum/TTL/etc), I’d argue - run time programmability (really anything that can’t be done within a single pass with a minimum number of actions )would do more harm than good. As a good use case - the market data you could look at - Barefoot economics (price to build programmability vs price market was willing to pay for it) and TH4 (the opposite of programmable silicon) numbers. I’d however love to be able to reprogram networking silicon rather than waiting for a respin (hello, VXLAN routing), I’m fine doing it off-path and in a highly controlled manner.
> 
> Wrt server vs networking equipment - proliferation of smart NICs and amount of investments clearly shows where the money is, from overall complexity prospective - further distribution to the edges is the only sustainable way to manage it.
> What’s missing?
> A set of well defined API’s and behaviors between the network and its edges, this is less obvious in plain IP networking, a pain in RDMA and ML clusters. This goes back to operability and end2end behavior (really service definition + set of SLA/SLO/KPIs associated). New overlay encapsulations allow for such innovations (Geneve, INT header, etc) and new silicon is capable (some more some less) of processing this data in near real time. If the edge that is service aware can get this data fast enough and the data itself is high fidelity and rich enough (within limits) to allow the edge to change its behavior - we would have solved many problems we are working on now.
> I’m not discounting more advanced use cases, in network compute, reduce functions, etc, however these are niche use cases and require very different economics to be successful.
> 
> /*weekend rant  
> 
> Cheers,
> Jeff
> 
> > On Feb 27, 2022, at 04:04, Marie-Jose Montpetit <[e-mail]> wrote:
> > 
> > 
> > "Fundamentally i think a lot more innovation would happen if the programmability of network equipment was as easy as programmability in DC servers.”
> > 
> > And we have a research “organisation” to look into this - COINRG. And we welcome research that will bring network node programmability “easy” but also useful both in the core and edge. Of course it’s not only routing that will achieve that but it is part of it.
> > 
> > mjm
> > 
> > Marie-José Montpetit, Ph.D.
> > [e-mail]
> > 
> > 
> > 
> > From: Toerless Eckert <[e-mail]>
> > Reply: Toerless Eckert <[e-mail]>
> > Date: February 27, 2022 at 4:28:17 AM
> > To: Jeff Tantsura <[e-mail]>
> > Cc: Dirk Trossen <dirk.trossen=[e-mail]>rg>, [e-mail] <[e-mail]>
> > Subject:  Re: [arch-d] [icnrg] recasting address semantics 
> > 
> >> Fundamentally i think a lot more innovation would happen if the programmability of network equipment was as easy as programmability in DC servers.

-- 
---
[e-mail]