So, if you launch your spacecraft and it blows up raining debris down on my house - your home nation is clearly responsible under Article VII.
That does not mean that Denmark will pay you any damage on your house. It means you get to sue me under danish law. The danish citizen (me) will then pay you the damages, if so determined by the danish judge.
All the other speculation such as a $100 million USD bounds has no basis in danish law and so will not be required. If I can't pay you, that too will play out accordingly to danish laws. Most likely that means it is just too bad for you. You wont be getting anything from the danish government either way.
It is the only way a civilized country can act - by following the laws by that country. A country is not a person that you can say "they owe me because the treaty says they are responsible" - you are only owed money if the laws of the country concur. And let me tell you right ahead, there are no laws in Denmark to the effect that government will step in and pay damages on behalf of a citizen if said citizen is unable to pay. And neither is there any such law in the US to my knowledge. If a SpaceX rocket drops on my car, I get to sue SpaceX in an american court for a new car.
I have a speed test site provided by my ISP, which usually runs fine, but when the "attacks" are in full swing my download speed drops to 1 or 2 mbps (should be around 16)
Your tiny DSL would be overwhelmed by even the smallest DoS attack imaginable. You would not be getting 1 or 2 Mbps - you would be getting absolutely nothing through at all.
It is more likely that your DSL is having trouble delivering the usual 16 Mbps due to electrical interference. Your ISP may be able to fix it by lowering your speed, which sucks, but it might be more stable. Or there might be nothing that can be done unless you can locate the source of the noise. Trouble is that the source might not anywhere near your home.
There are actually 2^128 possible IPv6 addresses. Ok, then you can cut it down by looking at BGP etc as proposed. But consider that the minimum IPv6 network every user gets is a/64 = every user has 2^64 addresses on his home network, just scanning one single user is not feasible. Not to even think of scanning the entire internet.
You can split an IPv6 address into blocks. The first 32 bits tells you what ISP. This is the part where the BGP trick can help. The next 32 bits is the network number. And the remaining 64 bits known as the interface identifier are more or less random assigned by the computers.
You can assume that the user router will respond to the all zero interface identifier. It would therefore be feasible to scan the routers. Every single ISP would take as long as scanning the entire IPv4 internet. But that means they could do it in 45 minutes apparently (longer for bigger ISPs with more/32s). Of course the routers should be configured to ignore anything from outside, but so should the IPv4 routers.
But actually hitting peoples computers, printers and so on, even assuming no firewalls, is simply not possible. It is not even the bandwidth of the attacker that limits you, but the bandwidth of the target user. How long would it take to transfer 2^64 packets down the average users crappy DSL?
On top of that you get privacy extension. This is a system where your computer changes address at random at regular intervals (at least once a day). If you did spend millions of years to do a scan, you would very likely never find a working address because the targets are moving.
Wonder if that happens with electric car batteries - how much do those cost again?
EV batteries deteriorate just like all other batteries. What you want to ask is how fast? That depends entirely on what car. Just like the batteries lasted much better on his old Mac.
Because the EV battery is such an expensive part of the car and a car is expected to last much longer than a laptop, they will do more to make it last longer. One trick is to stop charging at 80% and never go below 20%. Laptops will happily go to 100% even knowing this will kill the batteries quickly. And the user might run
Another is to climate control the battery. More expensive EVs like Tesla has climate control on the battery, so it will always be at optimum temperature. I have never seen a laptop with this feature. Nissan left this out on the first Leaf and got in a lot of trouble when the batteries started to deteriorate too fast in Arizona.
You should also remember that less capacity is not the same as failed. You probably would not replace the battery in an old EV just because it has shorter range now. Instead you sell it to someone who is fine with the shorter range. You will pay for it by getting a lesser resale value, but this is still cheaper than replacing the battery.
The 12V battery in an ICE car is something completely different. You can not assume that EV batteries will fail in 5 years, just because your 12V battery is crap. In fact may EVs come with 8 years of warranty on the battery.
Almost all Toyota Prius all the way back to the 1997 models are still running on their original battery.
This is not about getting 100 Gbps to your home. It is about building ISP networks with faster links. They are apparently not even trying to invent the 100 Gbps technology, they are just going to find out how it can be managed in a large network.
The ZDNET article only shows that Google has a/32. I own a/32 too so that is not extraordinary in any way whatsoever. In fact every ISP gets a/32, that is the minimum allocation these days...
The Royal Pingdom article lists Sixxs as the source. That would be the same link as I initially provided and which now lists the/13 as "returned". In fact it was never allocated, that was just some person that made that interpretation on his own.
The Royal Pingdom article does claim that the next largest allocation is a/19 to France Telecom, so no foundation for a/16 to Google there. I find it likely that the/16 rumour is just someone mistaking a/32 for a/16. It is an easy enough mistake to make. Google does have at least a/29 from RIPE but no/16 or anything like that.
The DoD assignment does seem a bit excessive. But they are the exception not the rule. I also wonder what ARIN can really do when the government of the US tells them to jump. The only thing they can do is to ask "how high?".
The RIRs always spreads the assignments so there is nothing strange in that. The idea is that if one of those/22 some day would need to be expanded, that is possible because there likely will be no adjacent assignment. This does not mean the space is reserved as such. If the world some day is lacking address space they will start allocating that space to somebody else.
It is also quite possible that IANA will ask ARIN to use some more of that/13 before ARIN can get more space from IANA.
I was partly wrong in my first response. The Sixxs guys does not seem to keep proper track of things. Here is the allocations that the US Department of Defense has:
They got 22x/22. However whoever calculated that equals one/13 is mistaken. It equals 69% of a/17. You need a bit less than 5 bits to express 22 nets. Apparently some guy noticed that most of those 22 networks were allocated from the same/13 block, but that in no way means the remaining of that/13 is reserved to DoD. If it was it would have been allocated to them.
There seems to be no foundation for the claim that Google got any exceedingly large allocations. They got two/32 from ARIN: http://whois.arin.net/rest/org/GOGL/nets
Google also got a/29 from RIPE. And possible more similar sized networks from other regions, which seems reasonable given their size.
Can you tell us what to the Google/16 block is? If not we can assume this is just wrong.
Agreed. I have no interest in having my TV connect to the internet.. or my fridge, or my toaster, or my toilet.
The internet is the _only_ connection my TV has. I skipped buying cable and terrestrial is not an option here.
It just happens that my TV can actually show a lot of TV content with just Internet. The national TV is available as streaming. And I got Netflix and HBO Nordic. I am never going to buy cable again.
Comparing the TV to the fridge, toaster and toilet is so misguided. The TV has a very real reason to be on the internet: The internet is the pipe to entertainment that I am viewing on the TV. It is the coax port on the TV that is going to be obsolete in the future. Already people like me are not using it anymore.
I want to se your C code for this simple Haskell function:
f x y = x*y
When applied to just one argument:
g = f 5
You get back an one argument function that will multiply by 5:
g 4 equals 20.
h = f 10
h 4 equals 40.
Your task is to write a C function, that does not memory leak (although it is hard enough even if you are allowed to leak), that based on some parameter will return a another function that is different each time. Like in the above Haskell code, I shall be able to invoke your C function multiple times, for example with the values 5 and 10 and get back new functions that will multiply with 5 and 10. The later must of course not override the behaviour of the former.
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 article was written by the guy that did the driver, I think we can assume he knows his stuff.
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...
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!). Packets need to be delayed when the controller needs to be queried and that is true for both OpenFlow and traditional switches. We are just fighting over some nano or possible microseconds here with no one showing that it actually matters. It very likely does not matter for the use case that Google uses for, or they wouldn't be doing it. At my company we are using it too and it works very well for us. We are an ISP by the way.
There might indeed exist a work case where a 10G flow just pops into existing out of nowhere and where even 1 microsecond delay on the forwarding of that stream is not acceptable. I am just having a real hard time imaging that case.
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.
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.
As to the blocking issue, only packets from the same (new) flow would be queued. Say this was a NAT implementation, all other existing connections would continue with no blocking. Or if it was a BGP implementation, all other already cached destinations would continue to be routed. Also given that it is possible for the controller to reply in less time that it takes to actually receive a full sized 1500 bytes packet, this blocking idea is a bit far fetched.
Also given that protocols like TCP do not just suddenly burst out 10G of packets, 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. 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.
It does not matter if it sends one bit per packet -- latency is per packet, not per byte. Packets must be sitting in a queue while the switch is waiting for response -- so the time for response is determined by the time for the queue to overflow, or the packet will have to be dropped. It will never work.
So you are saying my estimate of 200 ns delay is wrong? Give me your own calculations.
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.
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.
I am not going to comment on the rant about management protocols. OpenFlow is not a management protocol.
OpenFlow will only pass as much of the packet as you need to. For most cases that is just the headers. Say the controller is on a 10G interface and 100 bytes needs to be transferred out and then the reply will be about 100 bytes too. The time to process the packet will be the same or less compared to the switch build in controller (external controllers will generally be more powerful servers than the controller CPU in a switch or router). Time to transfer 200 bytes on a 10G is 200 ns.
Of course there might be multiple hops to reach the controller but that would be the network designers choice. Google apparently put the controllers adjacent to the switches, so they would have a direct connection.
Extra delay of this order, and only for the first packet in a new flow, is negligible. If it is a standard 1500 byte packet, it will be 200 ns to query the controller and then 1.5 microsecond to actually forward it.
By the way, there are multiple commercial available switches with OpenFlow support already. HP is retrofitting their entire product line with OpenFlow support. Juniper has experimental support too. Both companies seem to be doing it without rebuilding any ASIC or other hardware, considering adding OpenFlow is just a firmware update.
Nothing stops you from adding your own proprietary solution. But we need standards if we are to write software that will work on multiple brands and models.
Update counters and timers. Make decisions based on those counters and timers. Support multiple queues with different limits of delay etc. QoS. Rewrite source and destination IP address and UDP/TCP port numbers allowing the switch to do NAT without querying any external entity on a per packet basis. Add and remove VLAN, MPLS, etc tags, modify the tags, modify the MAC and much more. Automatically drop flow rules by certain events such as the last packet in a TCP flow or by counters, timers. Allow rules that recognise a missing rule and query the controller to add the rule.
It will basically do anything routers can do in the data plane without querying a controller.
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.
I recognize your belief that the controller software should run an a CPU in the same chassis as the data plane. This however does not necessary make the controller any faster reacting. 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. 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. As to having the controller in the same chassis, why don't you talk your employer into allowing uploading OpenFlow controllers to run on the control CPU? That is actually a good idea and might help sales of your product...
To implement NAT with OpenFlow you would need a rule that recognizes new connections and lets the controller add a new rule for that connection. The controller will not actually route or modify any packets, not even the initial one.
How the hell did you manage to conclude anyone here was talking about PCs with networking cards? The "cheap" switches I am talking about are products such as Juniper E4550 that got 32x 10G and 960 Gbps bandwidth for $19k. Compare that with Juniper M320 which is twice as expensive with only half as many 10G ports and 320 Gbps bandwidth.
Sure the M320 can do more in the data plane, but people are using it for stuff that the E4550 would do just fine, if the software would allow it.
Or you could go for a HP 5820X-24XG-SFP+ switch with 24x 10G and 488 Gbps bandwidth for just $5k.
If you believe the HP 5820X is a "linux router just a PC with more networking cards", then you are truly an idiot.
I will give you that the OpenFlow system is stupid in some ways. For example I can push a MPLS label on a packet, but I can not push a LISP header. Why not? Because they made separate instructions such as "push VLAN label" and "push MPLS label" - instead of a generic "push N bytes".
OpenFlow is two things. It is a language for the data plane. Not much different from what you are asking for. It is not turing complete, probably by design. So you can not make the data plane do just anything, but on the other hand you can guarantee that it will not do an infinite loop or use up all memory. It is possible to have OpenFlow in the data plane and still be able to guarantee that your data plane will switch at line speed. That would be impossible with a stronger turing complete data plane language. Yet they could have made it more generic, like having a generic push and pop.
OpenFlow is also a protocol. Currently we think the controller speaking the OpenFlow protocol must be external from the switch. But nothing prevents a switch manufacturer from granting access to the build in control plane computer in the switch. If it is just a Linux computer, as you say, I could just login and upload my controller software there. My software would still speak OpenFlow with the data plane, because that is the standard for how to program data planes. Also it would allow my program to be the same regardless if it is being used on a switch that allows uploading controller software or if it is run on an external server.
One thing is for sure thou - the big players like Cisco and Juniper do not want to go in this direction. You say that 50k juniper router providers lower latency than the cheap OpenFlow-switch - but that is just BS. They will switch at line speed and if the open source world gains access to program the things, there will be nothing to sell the expensive hardware on. We will be down to the pure specs of the hardware. Right now I see a lot of line rate 10G switches coming out at a very attractive price point - some of those made by these same brands but artificially limited in the software.
Can you point to any cheap switch that can hold 500.000 BGP routes in the dataplane? I didn't think so.
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?
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. I do not know where you work, but in my shop that is some savings that we will take.
Slashdot Mirror
If the power is out for 3 to 4 days you have no food, no water, no gasoline, no heat. The phone service is the least of your worries.
Truth is that people today have a much better chance of getting emergency services with their cell phones.
So, if you launch your spacecraft and it blows up raining debris down on my house - your home nation is clearly responsible under Article VII.
That does not mean that Denmark will pay you any damage on your house. It means you get to sue me under danish law. The danish citizen (me) will then pay you the damages, if so determined by the danish judge.
All the other speculation such as a $100 million USD bounds has no basis in danish law and so will not be required. If I can't pay you, that too will play out accordingly to danish laws. Most likely that means it is just too bad for you. You wont be getting anything from the danish government either way.
It is the only way a civilized country can act - by following the laws by that country. A country is not a person that you can say "they owe me because the treaty says they are responsible" - you are only owed money if the laws of the country concur. And let me tell you right ahead, there are no laws in Denmark to the effect that government will step in and pay damages on behalf of a citizen if said citizen is unable to pay. And neither is there any such law in the US to my knowledge. If a SpaceX rocket drops on my car, I get to sue SpaceX in an american court for a new car.
I have a speed test site provided by my ISP, which usually runs fine, but when the "attacks" are in full swing my download speed drops to 1 or 2 mbps (should be around 16)
Your tiny DSL would be overwhelmed by even the smallest DoS attack imaginable. You would not be getting 1 or 2 Mbps - you would be getting absolutely nothing through at all.
It is more likely that your DSL is having trouble delivering the usual 16 Mbps due to electrical interference. Your ISP may be able to fix it by lowering your speed, which sucks, but it might be more stable. Or there might be nothing that can be done unless you can locate the source of the noise. Trouble is that the source might not anywhere near your home.
I dont know what the robot would do. But you on the other hand would hit the baby and then crash after realizing that you just hit a baby.
E-Tag! That has to work, right?
ARGH!!!!!
Gee... I wonder if he's trying to tell me something like, oh I don't know, "I don't like being tracked".
By this point you are being tracked as the guy that blocked everything else. There is only going to be one of you.
DHCP is not used on home routers with ipv6. Your devices pick random addresses using privacy extension and duplicate address detection.
There are actually 2^128 possible IPv6 addresses. Ok, then you can cut it down by looking at BGP etc as proposed. But consider that the minimum IPv6 network every user gets is a /64 = every user has 2^64 addresses on his home network, just scanning one single user is not feasible. Not to even think of scanning the entire internet.
You can split an IPv6 address into blocks. The first 32 bits tells you what ISP. This is the part where the BGP trick can help. The next 32 bits is the network number. And the remaining 64 bits known as the interface identifier are more or less random assigned by the computers.
You can assume that the user router will respond to the all zero interface identifier. It would therefore be feasible to scan the routers. Every single ISP would take as long as scanning the entire IPv4 internet. But that means they could do it in 45 minutes apparently (longer for bigger ISPs with more /32s). Of course the routers should be configured to ignore anything from outside, but so should the IPv4 routers.
But actually hitting peoples computers, printers and so on, even assuming no firewalls, is simply not possible. It is not even the bandwidth of the attacker that limits you, but the bandwidth of the target user. How long would it take to transfer 2^64 packets down the average users crappy DSL?
On top of that you get privacy extension. This is a system where your computer changes address at random at regular intervals (at least once a day). If you did spend millions of years to do a scan, you would very likely never find a working address because the targets are moving.
Wonder if that happens with electric car batteries - how much do those cost again?
EV batteries deteriorate just like all other batteries. What you want to ask is how fast? That depends entirely on what car. Just like the batteries lasted much better on his old Mac.
Because the EV battery is such an expensive part of the car and a car is expected to last much longer than a laptop, they will do more to make it last longer. One trick is to stop charging at 80% and never go below 20%. Laptops will happily go to 100% even knowing this will kill the batteries quickly. And the user might run
Another is to climate control the battery. More expensive EVs like Tesla has climate control on the battery, so it will always be at optimum temperature. I have never seen a laptop with this feature. Nissan left this out on the first Leaf and got in a lot of trouble when the batteries started to deteriorate too fast in Arizona.
You should also remember that less capacity is not the same as failed. You probably would not replace the battery in an old EV just because it has shorter range now. Instead you sell it to someone who is fine with the shorter range. You will pay for it by getting a lesser resale value, but this is still cheaper than replacing the battery.
The 12V battery in an ICE car is something completely different. You can not assume that EV batteries will fail in 5 years, just because your 12V battery is crap. In fact may EVs come with 8 years of warranty on the battery.
Almost all Toyota Prius all the way back to the 1997 models are still running on their original battery.
This is not about getting 100 Gbps to your home. It is about building ISP networks with faster links. They are apparently not even trying to invent the 100 Gbps technology, they are just going to find out how it can be managed in a large network.
The ZDNET article only shows that Google has a /32. I own a /32 too so that is not extraordinary in any way whatsoever. In fact every ISP gets a /32, that is the minimum allocation these days...
The Royal Pingdom article lists Sixxs as the source. That would be the same link as I initially provided and which now lists the /13 as "returned". In fact it was never allocated, that was just some person that made that interpretation on his own.
The Royal Pingdom article does claim that the next largest allocation is a /19 to France Telecom, so no foundation for a /16 to Google there. I find it likely that the /16 rumour is just someone mistaking a /32 for a /16. It is an easy enough mistake to make. Google does have at least a /29 from RIPE but no /16 or anything like that.
The DoD assignment does seem a bit excessive. But they are the exception not the rule. I also wonder what ARIN can really do when the government of the US tells them to jump. The only thing they can do is to ask "how high?".
The RIRs always spreads the assignments so there is nothing strange in that. The idea is that if one of those /22 some day would need to be expanded, that is possible because there likely will be no adjacent assignment. This does not mean the space is reserved as such. If the world some day is lacking address space they will start allocating that space to somebody else.
It is also quite possible that IANA will ask ARIN to use some more of that /13 before ARIN can get more space from IANA.
I was partly wrong in my first response. The Sixxs guys does not seem to keep proper track of things. Here is the allocations that the US Department of Defense has:
http://whois.arin.net/rest/org/USDDD/nets
They got 22x /22. However whoever calculated that equals one /13 is mistaken. It equals 69% of a /17. You need a bit less than 5 bits to express 22 nets. Apparently some guy noticed that most of those 22 networks were allocated from the same /13 block, but that in no way means the remaining of that /13 is reserved to DoD. If it was it would have been allocated to them.
There seems to be no foundation for the claim that Google got any exceedingly large allocations. They got two /32 from ARIN: http://whois.arin.net/rest/org/GOGL/nets
Google also got a /29 from RIPE. And possible more similar sized networks from other regions, which seems reasonable given their size.
Can you tell us what to the Google /16 block is? If not we can assume this is just wrong.
The /13 was returned. The largest allocated prefix is currently /19: http://www.sixxs.net/tools/grh/dfp/
Agreed. I have no interest in having my TV connect to the internet .. or my fridge, or my toaster, or my toilet.
The internet is the _only_ connection my TV has. I skipped buying cable and terrestrial is not an option here.
It just happens that my TV can actually show a lot of TV content with just Internet. The national TV is available as streaming. And I got Netflix and HBO Nordic. I am never going to buy cable again.
Comparing the TV to the fridge, toaster and toilet is so misguided. The TV has a very real reason to be on the internet: The internet is the pipe to entertainment that I am viewing on the TV. It is the coax port on the TV that is going to be obsolete in the future. Already people like me are not using it anymore.
I want to se your C code for this simple Haskell function:
f x y = x*y
When applied to just one argument:
g = f 5
You get back an one argument function that will multiply by 5:
g 4 equals 20.
h = f 10
h 4 equals 40.
Your task is to write a C function, that does not memory leak (although it is hard enough even if you are allowed to leak), that based on some parameter will return a another function that is different each time. Like in the above Haskell code, I shall be able to invoke your C function multiple times, for example with the values 5 and 10 and get back new functions that will multiply with 5 and 10. The later must of course not override the behaviour of the former.
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 article was written by the guy that did the driver, I think we can assume he knows his stuff.
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...
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!). Packets need to be delayed when the controller needs to be queried and that is true for both OpenFlow and traditional switches. We are just fighting over some nano or possible microseconds here with no one showing that it actually matters. It very likely does not matter for the use case that Google uses for, or they wouldn't be doing it. At my company we are using it too and it works very well for us. We are an ISP by the way.
There might indeed exist a work case where a 10G flow just pops into existing out of nowhere and where even 1 microsecond delay on the forwarding of that stream is not acceptable. I am just having a real hard time imaging that case.
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
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.
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.
As to the blocking issue, only packets from the same (new) flow would be queued. Say this was a NAT implementation, all other existing connections would continue with no blocking. Or if it was a BGP implementation, all other already cached destinations would continue to be routed. Also given that it is possible for the controller to reply in less time that it takes to actually receive a full sized 1500 bytes packet, this blocking idea is a bit far fetched.
Also given that protocols like TCP do not just suddenly burst out 10G of packets, 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. 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.
It does not matter if it sends one bit per packet -- latency is per packet, not per byte. Packets must be sitting in a queue while the switch is waiting for response -- so the time for response is determined by the time for the queue to overflow, or the packet will have to be dropped. It will never work.
So you are saying my estimate of 200 ns delay is wrong? Give me your own calculations.
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.
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.
I am not going to comment on the rant about management protocols. OpenFlow is not a management protocol.
OpenFlow will only pass as much of the packet as you need to. For most cases that is just the headers. Say the controller is on a 10G interface and 100 bytes needs to be transferred out and then the reply will be about 100 bytes too. The time to process the packet will be the same or less compared to the switch build in controller (external controllers will generally be more powerful servers than the controller CPU in a switch or router). Time to transfer 200 bytes on a 10G is 200 ns.
Of course there might be multiple hops to reach the controller but that would be the network designers choice. Google apparently put the controllers adjacent to the switches, so they would have a direct connection.
Extra delay of this order, and only for the first packet in a new flow, is negligible. If it is a standard 1500 byte packet, it will be 200 ns to query the controller and then 1.5 microsecond to actually forward it.
By the way, there are multiple commercial available switches with OpenFlow support already. HP is retrofitting their entire product line with OpenFlow support. Juniper has experimental support too. Both companies seem to be doing it without rebuilding any ASIC or other hardware, considering adding OpenFlow is just a firmware update.
Nothing stops you from adding your own proprietary solution. But we need standards if we are to write software that will work on multiple brands and models.
An OpenFlow switch will:
Update counters and timers. Make decisions based on those counters and timers. Support multiple queues with different limits of delay etc. QoS. Rewrite source and destination IP address and UDP/TCP port numbers allowing the switch to do NAT without querying any external entity on a per packet basis. Add and remove VLAN, MPLS, etc tags, modify the tags, modify the MAC and much more. Automatically drop flow rules by certain events such as the last packet in a TCP flow or by counters, timers. Allow rules that recognise a missing rule and query the controller to add the rule.
It will basically do anything routers can do in the data plane without querying a controller.
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.
I recognize your belief that the controller software should run an a CPU in the same chassis as the data plane. This however does not necessary make the controller any faster reacting. 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. 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. As to having the controller in the same chassis, why don't you talk your employer into allowing uploading OpenFlow controllers to run on the control CPU? That is actually a good idea and might help sales of your product...
To implement NAT with OpenFlow you would need a rule that recognizes new connections and lets the controller add a new rule for that connection. The controller will not actually route or modify any packets, not even the initial one.
Please elaborate on what you mean by stateless. I already told you how it is not stateless.
No that is the point of OpenFlow. The switches becomes routers.
How the hell did you manage to conclude anyone here was talking about PCs with networking cards? The "cheap" switches I am talking about are products such as Juniper E4550 that got 32x 10G and 960 Gbps bandwidth for $19k. Compare that with Juniper M320 which is twice as expensive with only half as many 10G ports and 320 Gbps bandwidth.
Sure the M320 can do more in the data plane, but people are using it for stuff that the E4550 would do just fine, if the software would allow it.
Or you could go for a HP 5820X-24XG-SFP+ switch with 24x 10G and 488 Gbps bandwidth for just $5k.
If you believe the HP 5820X is a "linux router just a PC with more networking cards", then you are truly an idiot.
I will give you that the OpenFlow system is stupid in some ways. For example I can push a MPLS label on a packet, but I can not push a LISP header. Why not? Because they made separate instructions such as "push VLAN label" and "push MPLS label" - instead of a generic "push N bytes".
OpenFlow is two things. It is a language for the data plane. Not much different from what you are asking for. It is not turing complete, probably by design. So you can not make the data plane do just anything, but on the other hand you can guarantee that it will not do an infinite loop or use up all memory. It is possible to have OpenFlow in the data plane and still be able to guarantee that your data plane will switch at line speed. That would be impossible with a stronger turing complete data plane language. Yet they could have made it more generic, like having a generic push and pop.
OpenFlow is also a protocol. Currently we think the controller speaking the OpenFlow protocol must be external from the switch. But nothing prevents a switch manufacturer from granting access to the build in control plane computer in the switch. If it is just a Linux computer, as you say, I could just login and upload my controller software there. My software would still speak OpenFlow with the data plane, because that is the standard for how to program data planes. Also it would allow my program to be the same regardless if it is being used on a switch that allows uploading controller software or if it is run on an external server.
One thing is for sure thou - the big players like Cisco and Juniper do not want to go in this direction. You say that 50k juniper router providers lower latency than the cheap OpenFlow-switch - but that is just BS. They will switch at line speed and if the open source world gains access to program the things, there will be nothing to sell the expensive hardware on. We will be down to the pure specs of the hardware. Right now I see a lot of line rate 10G switches coming out at a very attractive price point - some of those made by these same brands but artificially limited in the software.
Can you point to any cheap switch that can hold 500.000 BGP routes in the dataplane? I didn't think so.
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?
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. I do not know where you work, but in my shop that is some savings that we will take.