Then enlighten us about your preferred consumption method of modern history.
Anything attributed to unknown or un-verifiable sources is likely to be a lie. Anything that is accompanied with ideological editorializing is likely to be a lie. Anything said by "historian" about anything hapening across some major ideological conflict is likely to be a lie. Anything said by "historian" about his own government is likely to be a lie. Anything said by American "historian" is likely to be a lie. Anything said by a pissed off writer is likely to be a lie.
Whatever left... Yeah, that's really not much, but you usually can trust your own memory and published documents when those documents were a part of some process where validity mattered.
he article was written by the guy that did the driver, I think we can assume he knows his stuff.
Most of the driver is just a copy of Intel driver, with additional functionality bolted on top. Whatever the author's abilities are, the goal was not to produce a working protocol stack, and benchmarks of this hack can't be used to predict anything but the behavior of this hack.
No it appears that if you want to switch more than 10-18 Gbit/s the computer would have a memory bandwidth problem. Trying to use multiple cores and NUMA might improve on that, but I do not think you would manage to build a 24 port switch that switches at line speed this way:-).
But if you could somehow get an external switch to do 99% of the work, this might work...
And then they would inevitably slow down this hack, too, what makes me doubt the validity of the measurements.
I am not sure how much more we can get out of this discussion. From my side I believe you are going too far in trying to make a problem out of something that actually works quite well for some very large companies (Google and HP!).
Those companies merely announced that they intend to use this "technology" somewhere. They are not throwing out the routers they have. They likely replace some level 2 and level 3 switches ("almost routers") and treat the whole thing as a fancier management protocol for simple mostly flat or statically configured networks that they have in abundance. For all we know, Google may already have no routers at all except for links between their data centers, as they are famous for customizing their hardware/network infrastructure for their own unique software infrastructure, and would probably gain more from multi-port servers connected by very primitive switches into clusters with VLAN or even physical topology following the topology of their applications' interfaces.
Packets need to be delayed when the controller needs to be queried and that is true for both OpenFlow and traditional switches.
Except traditional switches never have high-latency, unreliable links between their components, and the data formats follow the optimized design of ASICs and not someone's half-baked academic paper.
We are just fighting over some nano or possible microseconds here with no one showing that it actually matters.
Then why don't people just place Ethernet between a CPU and RAM? It's "nano or possibly microseconds", right?
Google uses for, or they wouldn't be doing it.
See above.
At my company we are using it too and it works very well for us. We are an ISP by the way.
If it works, then the way you use it, did not require anything complex to begin with, and you use it as yet another management protocol. You could have bought cheap level 3 switches before, and configure them to do exactly the same thing with command line, except with less buzzwords.
Ownership is a lot more than the right to deny use (and not always the right to deny use), and the "extensions of our body" argument is also flawed. The basis of "ownership" is our territorial instinct. If you move into my land (or speak to my woman), I will knock you in the head with my club. If I didn't do that, I would starve and have no offspring, so all people today descend from more or less territorial forefathers.
At no point in history, starting before apes that humans eventually evolved from, this was the case -- they were all social animals and controlled territory, food, etc. only as a group with complex hierarchy within the group that had absolutely nothing to do with ownership. Those loners in caves never existed, and could not possibly exist because humans never had physical traits necessary for surviving and defending an individual without a group. A hunter living alone in the woods, as much "close to nature" it seems, is something much more recent, brought by the development of technology. Personal property is also a recent cultural development, and even now it usually acts as a proxy for social status and power.
INB4 wikipedia is full of propaganda. Then correct them. Controversial articles are easy to spot.
If it's 19th to 21th century, it's someone regurgitating modern propaganda.
Dig deeper, make your own mind.
You can't "dig deeper" when all you have is a collection of propaganda workers and their parrots, all trying to out-shout each other while trying to keep the impression of legitimacy.
Onre thing that Wikipedia really sucks at, is history of anything after 18th century. Of course, this is one of the three microscopic ex-USSR Baltic countries. Their politicians' idea of history is worse than Wikipedia.
His echo service manages to do between 10 and 18 Gbit/s of traffic even at packet size of 60 bytes. And there is plenty of optimizations he could do to improve on that. The NIC supports CPU core affinity so he could have the load spread on multiple cores. The memory bandwidth issue could have been solved with NUMA. But even without really trying we are hitting the required response time on desktop hardware.
That's without data ever being accessed from userspace, no protocol stack, average packet size being half of the maximum, and there is a good possibility that the measurements are wrong, because then it would be easier to implement the whole switch by just stuffing multiple CPU cores into the device, and the whole problem would not exist.
The simple fact is that after the packet has been transferred over the 10G link it will go through a PCI Express (x8) bus and be processed by the Linux OS - the same OS that you earlier claimed to be running on the control plane of the switches designed by your company. The only difference here is that I would probably get a faster system CPU than would be in your hardware.
Actually in that driver it was not processed by anything -- copying is performed while in kernel. Data is mapped to userspace-accessible memory but userspace does not even touch it, everything happens in kernel, with network stack being completely bypassed. The only thing less relevant (but perfectly suitable for a switch if it was indeed that fast) would be forwarding done entirely in interrupt handlers.
Another important question is, it's still unknown what the latency of that thing is -- with enough buffers it can get very high, and we did not even take into account all the delays in hardware, sitting in the queues in the switches that forward them over the management network.
As to the blocking issue, only packets from the same (new) flow would be queued.
Except there is no new flow because it will be only created after the controller will produce a rule to identify it, so any packet may belong to it. And there is a matter of somehow expiring old rules based on lack of traffic that matches them. This works very well when the whole NAT or load balancing can be reduced to predefined static mapping with a hash. What is done already with managed switches, even cheap ones. There is no benefit in making fancy controllers do that.
Also given that protocols like TCP do not just suddenly burst out 10G of packets
But protocols like UDP (and convoluted monstrosities on top of them with multiple dependent mappings, like SIP), do.
, the next packet following the initial SYN packet is not likely to arrive before the SYN has been processed by both switch and controller and forwarded long ago.
Except there may be a DoS in progress that fakes those packets. On a host, you can have an algorithm that prevents them from eating your memory, so only real mappings (with both sides completing the handshake) end up being persistent. On a switch you have no way to implement such an algorithm because it does not fit into rules you can define by your protocol, what means, either your simple switch has to become a router, or it will not be able to provide such functionality without falling a victim to a simple SYN flood.
And again packets to other destinations will not be blocked while we wait for the controller and somehow I get the impression that you think they would.
There is also a matter of number of rules, size of internal RAM in ASICs that contains them (and it's a different kind of RA
So you are saying my estimate of 200 ns delay is wrong? Give me your own calculations.
This would work if data was transmitted instantly and there were no packets. 200ns round trip latency can be only achieved if network interface on the controller that can handle ten million packets per second. Network cards can only do 1-2 millions, and this does not count latency caused by a network stack of a general-purpose OS on the controller, and any delays in the switches along the way.
Yes the incoming packet is in a queue while the switch waits for response from the controller. That response can be there within 200 ns. In the meantime the switch is not blocked from processing further packets.
It is blocked because it does not yet have a rule that will determine the processing of any packet that follows, so any packet may happen to match it, and have to sit in the queue until the new rule arrives from the controller.
A 200 ns delay on the first packet in a flow of packets is so little that is barely measurable. You will be dealing with delays much larger than that simply because you want to send out a packet on a port that is already busy transmitting.
Switches always delay packets -- this is what queues are for. In this case, however, any packet that has to be processed by a controller means instant blocking of the input queue, something that network switch designers avoid like the plague. And just imagine what will happen if the response will be lost and everyone will wait for timeout and re-transmit. The loss of traffic will make those large routers look cheap in comparison.
Design can not be tested. Only implementation can be tested, and testing does not resuce the stupidity of people that work on the project, it just catches most glaring mistakes and worst brain farts. If the programmer writes buggy code, it will be still buggy after passing tests -- except if he is stupid or dishonest enough, he will be able to cover up bugs by writing workarounds for tested scenarios.
Agreed. For more than one reason, and from personal experience. I've had both, a crew of code monkeys and a small but incredibly efficient team of well paid but also very good programmers. To say that the latter were vastly outperforming the former (for less money in total, too) is an understatement.
That means, they work on the project that is already reduced to the worthless state, likely due to your inept management.
LOOK EVERYONE, shit programmers and shit managers are coming out of their closets!
I agree with you, in theory. But, in order for that 10x-100x to be achieved, conditions have to be conducive. It's like starting up that 600mph car to make a record run on the salt flats. If things are right, you can achieve phenomenal results. But, things usually aren't that optimal, and in a suboptimal environment, your gifted driver will be much less able to distinguish themselves from a merely good driver.
This is completely wrong.
Bad environment at work hurts everyone, however good programmer remains being good programmer until the point when project is so bad, it is worthless no matter who and how works on it.
Having watched things play out many times over a (eek) long career, I've observed that it's fairly rare that skill and opportunity coincide. If you find yourself in such a position, revel in it, as it probably will not last.
That's because you are a shit programmer who drags everyone down.
This however does not necessary make the controller any faster reacting.
Of course, it does. Latency of a PCI Express connection is negligible compared to any network interface. Properly organized DMA can perform multiple transfers, and get decisions from the local CPU while the packet is waiting in the queue.
Many switches only have limited bandwidth between data plane and control plane. It is assumed that most of the brunt work will be done in the data plane and that any work that needs to go through control will have higher latency and less bandwidth.
The problem is not bandwidth, it's latency. A tiny fraction of packets are supposed to reach CPU to trigger protocol-based decisions for their forwarding. However the decision (without data, no need to transfer it back if it's already queued) must come back fast. PCI Express can do that. Local DMA-capable bus interface to built-in core can do that. Management Ethernet to another device, passed through other switches can't no matter how fast it is.
It is this property that makes it possible to move the control plane out of the chassis. Is it perfect? No but it is a good start.
It's not a start. It's a start and the end because once standard like this is implemented, it's set in stone, and requires rebuilding ASIC to add anything. It's completely inflexible, and designed for convenience of software developers, not extensibility. Once there are devices with first version of the protocol, everyone will have to support it forever, and can only add a completely different protocol that only new devices will understand.
It will basically do anything routers can do in the data plane without querying a controller
And once this will be all implemented, it will become yet another implementation of a router.
I fail to see by what property you can call the above for "stateless". On the contrary it is a little programming language with state updates such as counters, timers and queue lengths and the ability to make decisions based on those.
And once it is all implemented, you will have a router, except all control is done in a limited "language", and it will have to control resources (queues, tables that now correspond to rules, not just physical ports) that will require ASIC and FPGA chips not unlike those used in expensive routers. It won't be cheaper or better, or more flexible -- in fact, it will cement the state of technology and protocol support at the moment this "standard" was created and provide no method for extension other than asking controller before deciding forwarding for each new address.
I recognize your belief that the controller software should run an a CPU in the same chassis as the data plane.
And then the design that relies on fixed-format exchange between controller and "dumb" switch is pointless, because router/switch implementations will have to accommodate new features, new hardware, and passing new kinds of protocols with appropriate kinds of QoS.
That would match Google naming scheme. If versions -> sweet, hardware platforms -> fatty, then, I guess, display architecture would be salty. Native X11 for Android would be Kipper.
Router is supposed to be able to generate and keep state of groups of protocol sessions (sometimes individual sessions), make decisions about forwarding and queuing immediately on the packet's arrival, maintain multiple queues with different limits of delay, etc. It is not allowed to forward traffic to the admin's iPhone for NAT, QoS, tunneling, load balancing, etc. -- it has to implement their logic locally.
On top of that it may have external logic that reacts to major changes in traffic statistics or changes in network topology/connectivity, and those may be implemented externally, however that's not all the router control logic does. As I have mentioned before, nothing is really saved by moving processors around, as switch still needs one, and once it has a processor, that processor can do everything remote controller would ever do, except without low reliability and enormous latency that comes with any form of a remote controller.
It's true that in its simplest form routing can be implemented as stateless filtering, header rewriting and switching, however those devices exist already, and they did not replace routers.
If you have your own fire department, healthcare system, and will supply them at your own expense to everyone affected by a fire caused by your improperly wired kitchen, and you and everyone in your family are willing to kill themselves if someone will die in that fire or be electrocuted? I guess, why not...
I know a few. Not many, but a few. I don't see them as exceptionally intelligent, they've just spent a lot of time and hard work getting educated about their field. I'll admit, the stuff they know, they know very well, and a great deal of it baffles me.
But to me "intelligence" is not measured by how well you know what you've had training for, it's measured by how well you can solve problems in areas where you've had no training at all. And based on that criteria, I have to give carpenters and mechanics very high scores.
Engineer is a person whose work is solving problems. That also happen to be a kind of problems that require engineering education to be understood. An engineer who can not solve problems in general is a shit engineer, and even though there are plenty of shit engineers, no company or team can do any engineering without good engineers. Obviously, an uneducated person such as yourself, would marvel at the solutions to trivial problems (that you do understand) by people you see around you. This is not however all that there is in the world.
A good 80% or so of people entering CS courses should instead be going to trade schools, or an apprenticeship with perhaps one or two days a week spent in the class room covering the theory they need.
No.
A good 80% (more like 95%) of people writing software have knowledge picked from apprenticeship and a bunch of random classes. This is why almost all software is such a disgusting, rickety, poorly slapped together, unmaintained and un-maintainable shit.
Can you point to any cheap switch that can hold 500.000 BGP routes in the dataplane? I didn't think so.
But I can build one if a customer asked me to.
You are also missing the point: Do you really want to pay extra for software features? Software that has been done way better in open source controllers?
Then maybe it would be a better idea to write real open source switch firmware instead of remote-control toys? Don't give me "it's all proprietary" crap, the OS is usually Linux, and hardware switching devices all use pretty simple definitions for packet processing.
A Juniper router with 6x 10 Gbit/s is $50,000. An OpenFlow enabled switch with four times as many 10 gig ports is only one tenth of that.
That's probably because the Juniper router has a tiny fraction of your cheap switch latency while doing more work. And, of course, because Juniper likes jacking up the prices because there is no open source alternative.
I do not know where you work, but in my shop that is some savings that we will take.
First of all I have to loudly proclaim that I do not speak for my employer because I work for a hardware company that makes network equipment. And likely don't even know what is my employer's position on this is, or if it has any. I believe I can talk about this because information about approximate amounts of processing capabilities of hardware used in modern switches can be easily derived from published descriptions, so it's not anyone's secret.
Personally I am just as frustrated about the lack of open source fully functional switch components as the users, but seeing humongous amounts of processing power available in "cheap" devices every day right in front of my face, I also recognize that this "SDN" craze is a distraction that creates narrowly defined "open interface" as a barrier for development of open standards and open source solutions.
Someone will inevitably implement it on the level of the chip, stuff "controller" back into the CPU on the switch where it always belonged, and then everyone will find out that the mechanism and protocol are crippled, and require huge amount of extensions. Extensions will be all proprietary, and here we go again, another cycle of pseudo-open standards at least as bad as ACPI, and even more cemented in hardware, so no one will be able to fix them. Then Microsoft, or worse, will jump in with their "solution" that breaks everything but at the moment works better than now-crippled "open standard", and everyone, like sheep, will jump onto stuffing Windows into their network switches. When that blows up, it will be too late to pick up the pieces, so Cisco and Juniper will remain secure in their monopoly for fast and reliable, and Microsoft (or whoever will be playing that game at the moment) will take over the market of "small business" routers that will require daily reboots.
Does it sound like something we already went through in each and every aspect of computing OTHER THAN NETWORKING?
Alternatively, if all this crap is abandoned, and switch chip manufacturers adopt a standard for compiling rules from a text source in some language, they will be able to have a (likely proprietary) compiler loading rules generated by open source components, or written by people, and those compilers will run on the switches' large CPUs. Stateless, stateful, with external protocol having access to internal state, etc. Not unlike what happens with shaders when they are loaded into GPUs.
But then no one needs micromanaged "SDN" protocols with fixed structures containing extra-special fields for every protocol and feature known to man, everything just downloads lists of objects from hardware (over HTTPS if over the network), generates text representation of the rules, sends them to devices (over HTTPS if they have to go over the network), in the same manner compiles rules implemented on the processors, if any nee
Slashdot Mirror
Then enlighten us about your preferred consumption method of modern history.
Anything attributed to unknown or un-verifiable sources is likely to be a lie.
Anything that is accompanied with ideological editorializing is likely to be a lie.
Anything said by "historian" about anything hapening across some major ideological conflict is likely to be a lie.
Anything said by "historian" about his own government is likely to be a lie.
Anything said by American "historian" is likely to be a lie.
Anything said by a pissed off writer is likely to be a lie.
Whatever left... Yeah, that's really not much, but you usually can trust your own memory and published documents when those documents were a part of some process where validity mattered.
So you will just accuse me of bias because you happen to believe the propaganda version?
he article was written by the guy that did the driver, I think we can assume he knows his stuff.
Most of the driver is just a copy of Intel driver, with additional functionality bolted on top. Whatever the author's abilities are, the goal was not to produce a working protocol stack, and benchmarks of this hack can't be used to predict anything but the behavior of this hack.
No it appears that if you want to switch more than 10-18 Gbit/s the computer would have a memory bandwidth problem. Trying to use multiple cores and NUMA might improve on that, but I do not think you would manage to build a 24 port switch that switches at line speed this way :-).
But if you could somehow get an external switch to do 99% of the work, this might work...
And then they would inevitably slow down this hack, too, what makes me doubt the validity of the measurements.
I am not sure how much more we can get out of this discussion. From my side I believe you are going too far in trying to make a problem out of something that actually works quite well for some very large companies (Google and HP!).
Those companies merely announced that they intend to use this "technology" somewhere. They are not throwing out the routers they have. They likely replace some level 2 and level 3 switches ("almost routers") and treat the whole thing as a fancier management protocol for simple mostly flat or statically configured networks that they have in abundance. For all we know, Google may already have no routers at all except for links between their data centers, as they are famous for customizing their hardware/network infrastructure for their own unique software infrastructure, and would probably gain more from multi-port servers connected by very primitive switches into clusters with VLAN or even physical topology following the topology of their applications' interfaces.
Packets need to be delayed when the controller needs to be queried and that is true for both OpenFlow and traditional switches.
Except traditional switches never have high-latency, unreliable links between their components, and the data formats follow the optimized design of ASICs and not someone's half-baked academic paper.
We are just fighting over some nano or possible microseconds here with no one showing that it actually matters.
Then why don't people just place Ethernet between a CPU and RAM? It's "nano or possibly microseconds", right?
Google uses for, or they wouldn't be doing it.
See above.
At my company we are using it too and it works very well for us. We are an ISP by the way.
If it works, then the way you use it, did not require anything complex to begin with, and you use it as yet another management protocol. You could have bought cheap level 3 switches before, and configure them to do exactly the same thing with command line, except with less buzzwords.
Ownership is a lot more than the right to deny use (and not always the right to deny use), and the "extensions of our body" argument is also flawed. The basis of "ownership" is our territorial instinct. If you move into my land (or speak to my woman), I will knock you in the head with my club. If I didn't do that, I would starve and have no offspring, so all people today descend from more or less territorial forefathers.
At no point in history, starting before apes that humans eventually evolved from, this was the case -- they were all social animals and controlled territory, food, etc. only as a group with complex hierarchy within the group that had absolutely nothing to do with ownership. Those loners in caves never existed, and could not possibly exist because humans never had physical traits necessary for surviving and defending an individual without a group. A hunter living alone in the woods, as much "close to nature" it seems, is something much more recent, brought by the development of technology. Personal property is also a recent cultural development, and even now it usually acts as a proxy for social status and power.
INB4 wikipedia is full of propaganda. Then correct them. Controversial articles are easy to spot.
If it's 19th to 21th century, it's someone regurgitating modern propaganda.
Dig deeper, make your own mind.
You can't "dig deeper" when all you have is a collection of propaganda workers and their parrots, all trying to out-shout each other while trying to keep the impression of legitimacy.
Onre thing that Wikipedia really sucks at, is history of anything after 18th century.
Of course, this is one of the three microscopic ex-USSR Baltic countries. Their politicians' idea of history is worse than Wikipedia.
That is bullshit. Here is a guy that benchmarked the Intel X520 10G NIC that wrote a small piece titled "Packet I/O Performance on a low-end desktop": http://shader.kaist.edu/packetshader/io_engine/benchmark/i3.html [kaist.edu]
His echo service manages to do between 10 and 18 Gbit/s of traffic even at packet size of 60 bytes. And there is plenty of optimizations he could do to improve on that. The NIC supports CPU core affinity so he could have the load spread on multiple cores. The memory bandwidth issue could have been solved with NUMA. But even without really trying we are hitting the required response time on desktop hardware.
That's without data ever being accessed from userspace, no protocol stack, average packet size being half of the maximum, and there is a good possibility that the measurements are wrong, because then it would be easier to implement the whole switch by just stuffing multiple CPU cores into the device, and the whole problem would not exist.
The simple fact is that after the packet has been transferred over the 10G link it will go through a PCI Express (x8) bus and be processed by the Linux OS - the same OS that you earlier claimed to be running on the control plane of the switches designed by your company. The only difference here is that I would probably get a faster system CPU than would be in your hardware.
Actually in that driver it was not processed by anything -- copying is performed while in kernel. Data is mapped to userspace-accessible memory but userspace does not even touch it, everything happens in kernel, with network stack being completely bypassed. The only thing less relevant (but perfectly suitable for a switch if it was indeed that fast) would be forwarding done entirely in interrupt handlers.
Another important question is, it's still unknown what the latency of that thing is -- with enough buffers it can get very high, and we did not even take into account all the delays in hardware, sitting in the queues in the switches that forward them over the management network.
As to the blocking issue, only packets from the same (new) flow would be queued.
Except there is no new flow because it will be only created after the controller will produce a rule to identify it, so any packet may belong to it. And there is a matter of somehow expiring old rules based on lack of traffic that matches them. This works very well when the whole NAT or load balancing can be reduced to predefined static mapping with a hash. What is done already with managed switches, even cheap ones. There is no benefit in making fancy controllers do that.
Also given that protocols like TCP do not just suddenly burst out 10G of packets
But protocols like UDP (and convoluted monstrosities on top of them with multiple dependent mappings, like SIP), do.
, the next packet following the initial SYN packet is not likely to arrive before the SYN has been processed by both switch and controller and forwarded long ago.
Except there may be a DoS in progress that fakes those packets. On a host, you can have an algorithm that prevents them from eating your memory, so only real mappings (with both sides completing the handshake) end up being persistent. On a switch you have no way to implement such an algorithm because it does not fit into rules you can define by your protocol, what means, either your simple switch has to become a router, or it will not be able to provide such functionality without falling a victim to a simple SYN flood.
And again packets to other destinations will not be blocked while we wait for the controller and somehow I get the impression that you think they would.
There is also a matter of number of rules, size of internal RAM in ASICs that contains them (and it's a different kind of RA
So you are saying my estimate of 200 ns delay is wrong? Give me your own calculations.
This would work if data was transmitted instantly and there were no packets. 200ns round trip latency can be only achieved if network interface on the controller that can handle ten million packets per second. Network cards can only do 1-2 millions, and this does not count latency caused by a network stack of a general-purpose OS on the controller, and any delays in the switches along the way.
Yes the incoming packet is in a queue while the switch waits for response from the controller. That response can be there within 200 ns. In the meantime the switch is not blocked from processing further packets.
It is blocked because it does not yet have a rule that will determine the processing of any packet that follows, so any packet may happen to match it, and have to sit in the queue until the new rule arrives from the controller.
A 200 ns delay on the first packet in a flow of packets is so little that is barely measurable. You will be dealing with delays much larger than that simply because you want to send out a packet on a port that is already busy transmitting.
Switches always delay packets -- this is what queues are for. In this case, however, any packet that has to be processed by a controller means instant blocking of the input queue, something that network switch designers avoid like the plague. And just imagine what will happen if the response will be lost and everyone will wait for timeout and re-transmit. The loss of traffic will make those large routers look cheap in comparison.
armature terrorist attack
lol wut
Design can not be tested. Only implementation can be tested, and testing does not resuce the stupidity of people that work on the project, it just catches most glaring mistakes and worst brain farts. If the programmer writes buggy code, it will be still buggy after passing tests -- except if he is stupid or dishonest enough, he will be able to cover up bugs by writing workarounds for tested scenarios.
My apologies, the very opposite applies here -- the comment about the shit programmers/managers are for http://news.slashdot.org/comments.pl?sid=3764705&cid=43768603 and http://news.slashdot.org/comments.pl?sid=3764705&cid=43768647
Agreed. For more than one reason, and from personal experience. I've had both, a crew of code monkeys and a small but incredibly efficient team of well paid but also very good programmers. To say that the latter were vastly outperforming the former (for less money in total, too) is an understatement.
That means, they work on the project that is already reduced to the worthless state, likely due to your inept management.
LOOK EVERYONE, shit programmers and shit managers are coming out of their closets!
I agree with you, in theory. But, in order for that 10x-100x to be achieved, conditions have to be conducive. It's like starting up that 600mph car to make a record run on the salt flats. If things are right, you can achieve phenomenal results. But, things usually aren't that optimal, and in a suboptimal environment, your gifted driver will be much less able to distinguish themselves from a merely good driver.
This is completely wrong.
Bad environment at work hurts everyone, however good programmer remains being good programmer until the point when project is so bad, it is worthless no matter who and how works on it.
Having watched things play out many times over a (eek) long career, I've observed that it's fairly rare that skill and opportunity coincide. If you find yourself in such a position, revel in it, as it probably will not last.
That's because you are a shit programmer who drags everyone down.
This however does not necessary make the controller any faster reacting.
Of course, it does. Latency of a PCI Express connection is negligible compared to any network interface. Properly organized DMA can perform multiple transfers, and get decisions from the local CPU while the packet is waiting in the queue.
Many switches only have limited bandwidth between data plane and control plane. It is assumed that most of the brunt work will be done in the data plane and that any work that needs to go through control will have higher latency and less bandwidth.
The problem is not bandwidth, it's latency. A tiny fraction of packets are supposed to reach CPU to trigger protocol-based decisions for their forwarding. However the decision (without data, no need to transfer it back if it's already queued) must come back fast. PCI Express can do that. Local DMA-capable bus interface to built-in core can do that. Management Ethernet to another device, passed through other switches can't no matter how fast it is.
It is this property that makes it possible to move the control plane out of the chassis.
Is it perfect? No but it is a good start.
It's not a start. It's a start and the end because once standard like this is implemented, it's set in stone, and requires rebuilding ASIC to add anything. It's completely inflexible, and designed for convenience of software developers, not extensibility. Once there are devices with first version of the protocol, everyone will have to support it forever, and can only add a completely different protocol that only new devices will understand.
It will basically do anything routers can do in the data plane without querying a controller
And once this will be all implemented, it will become yet another implementation of a router.
I fail to see by what property you can call the above for "stateless". On the contrary it is a little programming language with state updates such as counters, timers and queue lengths and the ability to make decisions based on those.
And once it is all implemented, you will have a router, except all control is done in a limited "language", and it will have to control resources (queues, tables that now correspond to rules, not just physical ports) that will require ASIC and FPGA chips not unlike those used in expensive routers. It won't be cheaper or better, or more flexible -- in fact, it will cement the state of technology and protocol support at the moment this "standard" was created and provide no method for extension other than asking controller before deciding forwarding for each new address.
I recognize your belief that the controller software should run an a CPU in the same chassis as the data plane.
And then the design that relies on fixed-format exchange between controller and "dumb" switch is pointless, because router/switch implementations will have to accommodate new features, new hardware, and passing new kinds of protocols with appropriate kinds of QoS.
That would match Google naming scheme. If versions -> sweet, hardware platforms -> fatty, then, I guess, display architecture would be salty. Native X11 for Android would be Kipper.
Router is supposed to be able to generate and keep state of groups of protocol sessions (sometimes individual sessions), make decisions about forwarding and queuing immediately on the packet's arrival, maintain multiple queues with different limits of delay, etc. It is not allowed to forward traffic to the admin's iPhone for NAT, QoS, tunneling, load balancing, etc. -- it has to implement their logic locally.
On top of that it may have external logic that reacts to major changes in traffic statistics or changes in network topology/connectivity, and those may be implemented externally, however that's not all the router control logic does. As I have mentioned before, nothing is really saved by moving processors around, as switch still needs one, and once it has a processor, that processor can do everything remote controller would ever do, except without low reliability and enormous latency that comes with any form of a remote controller.
It's true that in its simplest form routing can be implemented as stateless filtering, header rewriting and switching, however those devices exist already, and they did not replace routers.
The switches become stateless routers. A stateless router to a router is what unmanaged switch is to a managed switch.
That is an elitest point of view and I agree with him.
Unfortunately people who spell like you just did, aren't allowed to agree with elitist points of view.
If you have your own fire department, healthcare system, and will supply them at your own expense to everyone affected by a fire caused by your improperly wired kitchen, and you and everyone in your family are willing to kill themselves if someone will die in that fire or be electrocuted? I guess, why not...
I know a few. Not many, but a few. I don't see them as exceptionally intelligent, they've just spent a lot of time and hard work getting educated about their field. I'll admit, the stuff they know, they know very well, and a great deal of it baffles me.
But to me "intelligence" is not measured by how well you know what you've had training for, it's measured by how well you can solve problems in areas where you've had no training at all. And based on that criteria, I have to give carpenters and mechanics very high scores.
Engineer is a person whose work is solving problems. That also happen to be a kind of problems that require engineering education to be understood. An engineer who can not solve problems in general is a shit engineer, and even though there are plenty of shit engineers, no company or team can do any engineering without good engineers. Obviously, an uneducated person such as yourself, would marvel at the solutions to trivial problems (that you do understand) by people you see around you. This is not however all that there is in the world.
A good 80% or so of people entering CS courses should instead be going to trade schools, or an apprenticeship with perhaps one or two days a week spent in the class room covering the theory they need.
No.
A good 80% (more like 95%) of people writing software have knowledge picked from apprenticeship and a bunch of random classes. This is why almost all software is such a disgusting, rickety, poorly slapped together, unmaintained and un-maintainable shit.
Just how many engineers do you know?
Better yet, answer this: WHY would anyone but another engineer know an engineer?
Quantity has a quality all its own
Dear grand-grandson, I have studied this when it was properly attributed to Hegel.
Can you point to any cheap switch that can hold 500.000 BGP routes in the dataplane? I didn't think so.
But I can build one if a customer asked me to.
You are also missing the point: Do you really want to pay extra for software features? Software that has been done way better in open source controllers?
Then maybe it would be a better idea to write real open source switch firmware instead of remote-control toys? Don't give me "it's all proprietary" crap, the OS is usually Linux, and hardware switching devices all use pretty simple definitions for packet processing.
A Juniper router with 6x 10 Gbit/s is $50,000. An OpenFlow enabled switch with four times as many 10 gig ports is only one tenth of that.
That's probably because the Juniper router has a tiny fraction of your cheap switch latency while doing more work. And, of course, because Juniper likes jacking up the prices because there is no open source alternative.
I do not know where you work, but in my shop that is some savings that we will take.
First of all I have to loudly proclaim that I do not speak for my employer because I work for a hardware company that makes network equipment. And likely don't even know what is my employer's position on this is, or if it has any. I believe I can talk about this because information about approximate amounts of processing capabilities of hardware used in modern switches can be easily derived from published descriptions, so it's not anyone's secret.
Personally I am just as frustrated about the lack of open source fully functional switch components as the users, but seeing humongous amounts of processing power available in "cheap" devices every day right in front of my face, I also recognize that this "SDN" craze is a distraction that creates narrowly defined "open interface" as a barrier for development of open standards and open source solutions.
Someone will inevitably implement it on the level of the chip, stuff "controller" back into the CPU on the switch where it always belonged, and then everyone will find out that the mechanism and protocol are crippled, and require huge amount of extensions. Extensions will be all proprietary, and here we go again, another cycle of pseudo-open standards at least as bad as ACPI, and even more cemented in hardware, so no one will be able to fix them. Then Microsoft, or worse, will jump in with their "solution" that breaks everything but at the moment works better than now-crippled "open standard", and everyone, like sheep, will jump onto stuffing Windows into their network switches. When that blows up, it will be too late to pick up the pieces, so Cisco and Juniper will remain secure in their monopoly for fast and reliable, and Microsoft (or whoever will be playing that game at the moment) will take over the market of "small business" routers that will require daily reboots.
Does it sound like something we already went through in each and every aspect of computing OTHER THAN NETWORKING?
Alternatively, if all this crap is abandoned, and switch chip manufacturers adopt a standard for compiling rules from a text source in some language, they will be able to have a (likely proprietary) compiler loading rules generated by open source components, or written by people, and those compilers will run on the switches' large CPUs. Stateless, stateful, with external protocol having access to internal state, etc. Not unlike what happens with shaders when they are loaded into GPUs.
But then no one needs micromanaged "SDN" protocols with fixed structures containing extra-special fields for every protocol and feature known to man, everything just downloads lists of objects from hardware (over HTTPS if over the network), generates text representation of the rules, sends them to devices (over HTTPS if they have to go over the network), in the same manner compiles rules implemented on the processors, if any nee