On 26/11/2018 21:59, Joe Touch wrote:
On 2018-11-26 09:53, Gert Doering wrote:
Hi,
...
As people have explained in great detail, there's work that the routers
are built to do, where the number of packets they can handle is nearly
arbitrarily high.
Then there's packets that are seen as an exception, and handled in a
not-as-powerful path. Back then, when the Internet was new, these
exceptional packets were considered "something we'll handle when the
need arises", and it mostly worked.
Translation - "we cheated", and that's not working anymore. Agreed.
Fundamentally it is about economics.
Doing complex processing in the fast path is expensive. It is expensive
to have the cycles
available. In designs that use fixed logic assistance it is pretty much
infeasible to cope with
multiple options as the combinatorial complexity explodes on you.
As the packet size increases this is also expensive in terms of the fast
packet caching memory
needed.
In the days when the fast path/slow path decision was first taken, there
were also fundamental
limits on what could be implemented at any price thus pushing the cost
from equipment
to physical infrastructure. There are some use cases that say that we
need to get 1Tb/s
to the host for some applications, so we cannot be sure that the
fundamental parsing limit
problem will not re-occur.
In any case, fast feature = silicon = cost and whilst you can or at
least could ride More's law,
at the end of the day you have to trade features against port density
against power against
capex against opex. ... and all this is without the issue of the
internet carbon footprint
coming under scrutiny.
So what this came down to at the time the feature split was taken was a
decision on economics,
i.e. is the cost of the additional feature worth the price paid? That is
still true and I think that
we need to remember that as we add non-optional features into the fast
path.
- Stewart
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec