Market Leader Programs
5G Transport - A 2023 Heavy Reading Survey
2023 Open RAN Operator Survey
Coherent Optics at 100G, 400G, and Beyond
Open RAN Platforms and Architectures Operator Survey
Cloud Native 5G Core Operator Survey
Bridging the Digital Divide
5G Network Slicing Operator Survey
Open, Automated & Programmable Transport
The Journey to Cloud Native
- I dont see why you bought into this "caspian
comes out" nonsense. They have been out in the
open for a very long time. This is almost a
re-launch. They re-did all the graphics on their
web-page, but there is little or no new content.
They promised an IPO. They promised customers.
They launched the product. And now they claim
to be coming out of stealth?
- The micro-flows are maintained through a
passive mechanism. Its not like RSVP. Its like
they try to watch packets going by and assign
them to flows as the scheduler thinks best.
Any passive state mechanism like this is very
open to DOS attacks. You can change the
core router's traffic handling behavior by
throwing the right packets at it.
- There is a tradeoff in how much the system
knows about a microflow vs. how many microflows
can be supported at any given time. Saying you
can handle "millions of flows" sounds nice, but
the memory requirements for doing it don't
seem to add up.
- C&W is a dead issue. C&W isn't going to be
buying anything from them for a long time. They
bet alot on C&W and its not going to happen.
- They can talk about trials and asia, but they
didn't mention a single name today.
In public network applications, the number of flows can scale with the volume of packets you are forwarding... and it tends toward infinity with time; the horizon at which flows are aged, and speed with which they can be created or destroyed determines whether this will be successful.
If at any point, you box should happen to fall behind, then all of Skeptic's predictions manifest themselves, even without malice in the equation.
This would be why vendors with great ideas like this have either evolved their architecutre, or evaporated... remember Ipsilon?
u
I can say that skeptic knows what he is talking about. Assigning a flow to every packet without valid Call Acceptance proceedures makes a router open to simple randomized source DOS attacks. Even common occurences of route flaps will change huge amounts of flow state that will negate any benifits of caching routes. If Caspian were to implement their chips without a programmable front end header parser, it would be very difficult to change any linerate classification mechanisms. It is just very expensive in compute time and memory resources to keep too much state.
The Diff-serv model of router design for emerging services, scalability and QoS makes even more sense today when we have the technology of doing line rate route lookup and classification, which only further diminish any benifit of keeping huge amounts of router state. (think hot, expensive, and monolithic, not like a cloud of cheap simple routers implementing a behaviour)
As to 40% layoff: how mush of an ASIC team does Caspian have, and haven't they been losing talent for a while...
Plus, where did the Bronze head of Larry go?
=============================================
This seems to be Cisco like marketing once again. If Cisco can't do something they would comeup with story that the feature is impossible while working to deliver the same after a year or two.
ps: I don't work for Caspian
Also, I don't see why a properly traffic engineered MPLS network can't deliver ATM QoS -- or indeed any other predictable QoS you care to dream up. You only have to have an aggregate traffic trunk for each of the ATM QoSes. Each flow doesn't have to have its own special treatment -- if two flows need the same treatment, you can aggregate them.
What are these people on?
Cheers,
Digerato
aggregate QoS is adequate in the core. per-flow QoS is neither necessary nor manageable. If this is their only differentiation, God help them.
What are these people on?
----------------------------
1) They convinced themselves that the only way
to build a router past a certain size was to
build a distributed packet processing system.
2) When you build a system like that and try
to scale it, you end up having to solve
mesh utilization issues. And the way they
solved the mesh utilization issues was to
micro-schedule everything across the complex on
a flow basis.
3) Many people who started down that road gave
up early. The problem with the distributed
mesh architecture as scalable router is that
the "router" starts to take on the characteristics
and the problems associated with a pile of
routers. You start trying to build routers
inside the router. And when you reach that point,
you end up questioning the whole concept.
When I get to a point where I have a "router"
that is actually several routers internally
running propritary routing protocols (which
in caspian's case look like MPLS), what is
the value vs. having several routers?
The unique value I see is that the flow
management is adaptive. Its supposed to
automatically identify the flows as opposed to
traditional
ATM or MPLS where the flows have to manually
be determined. But its only of value if it
works. Testing/debugging/validating anything
that makes assumptions about micro-flows and
traffic behavior in the internet would seem
really difficult.