Oct/096
Cautious Optimism, Irrational Exuberance, Full-Circle Come-a-bouts, and Economic Recovery
Everything seems to come full circle in IT...
Cautious optimism is a term I have been having many discussions lately with friends and analysts about - whether we are seeing true economic recovery or a bit of a 'W' and whether to make serious investments in planned growth or not. Candidly, in IT we have compressed capital spending for a while, so it could just be a bit of elasticity - although one major thing strikes me as different.
In the current world order many of the IT investments seem to be directly proportional to short-mid term ROI, sure everyone wants to build for 5-10 years, but they also want to see real business results, right now.
Mostly this means that new project types are getting priority and IT is finding creative and innovative ways of delivering near-term business value without, hopefully, taking their eye off the architectural ball. Ideally we can do both- deliver short-term value creation, while building towards a longer-term vision that enables IT to reinvent itself and infrastructure to transcend generational shifts. Sadly this is not always the case, some companies and people seem to want to either over-rotate on short-term. Sadder, others refuse to admit the world is changing. Even worse are those who keep their head in the sand and cannot move at all. Denying change happens is dooming almost any business to failure, embracing a fickle trend too quickly can be just as painful, and relying on past formulas from previous successes doesn't always work.
You may wonder where I am going with this. Over the past thirteen years I have seen a lot of things change and come full circle- Cut-Through Switching, Lossless L2 Networks, Ring Topologies, Hosting/Cloud/Insource/Outsource. Universal truth - things change and open and experienced minds that can capture this change tend to prevail.
Architectures have to change with the trend, the old way of doing things is not always the best- althought there are always viable lessons to be learned and due respect should be paid to past success.
Looking at networking, especially in the data center there are a lot of architectural changes in play. Obviously, the changes being driven to effect convergence between Ethernet and FibreChannel is a big one. The other is the collapsing of layers and efforts to simplify the topologies while increasing the scale of operations - I think in my next post or two I will have to explore these some more, what are your thoughts on other architectural changes in the data center network?
dg
Aug/0912
America’s Data Center Top 40 for QoS Implementations
a rainbow of fruit flavors for the network
Do you really use network quality of service within the glass house data center? This is a question I have been pondering pretty much all day- I get that on the costly WAN links we almost all use it. I also completely acknowledge that most engineers plan to use some of the QoS features within the data center, but what do we really use? Which features are necessary and which are just... well... extraneous?
Here's my thought- I think there are some QoS 'hit songs' implemented in the data center, and some that just are not that appropriate for this iMix.
Bad Boy Bad Boy, whatcha gonna queue....
No matter how many security products we surround ourselves with we all have the 'time out queue' for traffic that just isn't, well, good. It's for those pesky control plane DoS attacks, the misbehaving broadcast storm NIC, or that one application that just won't shut up.
Voices Carry
For some reason I have the 80's Til Tuesday song in my head by the same name- but most engineers I have talked with seem to set up, by default, a strict priority queue for voice traffic, then never,ever touch it again because it just works.
Marky Mark and the Funky Bunch
We all use markers, especially at the edge where we can have maximum visibility to what comes from a single host, and mark it up appropriately so that we don't have to continuously re-inspect and re-apply policy everywhere. Tag at the edge, queue in the core, shape on the WAN or point of massive congestion/cost.
(Don't) Drop it like it's Hot
No matter what religious SCSI encapsulation you love- FibreChannel, FibreChannel over Ethernet, iSCSI or even file based alternatives such as NFS or CIFS storage just performs better when is is not dropped. As much as I love technologies like Aspera for moving large files from A-to-B, until it is integrated in my host stack (which would monumentally rock for copying my iTunes library to S3 btw, hint...) the world will be dependent on TCP-guaranteed or PFC/BCN guaranteed storage delivery for a while - so we need a "lossless don't-drop-me-please" queue.
Shape ya Tailfeather
As we hit congestion and contention for bandwidth in a well designed data center this happens at the cost-center link, i.e. the edge router: this is where I apply large buffers, shapers, and policers to ensure that traffic can en-queue long enough to get onto the link, we can also adhere to Peter Lothberg's long-time rule of providing enough buffer to handle a round-trip-response of around the world or ~300ms. Shaping the previously marked-up traffic onto the link while trying to get all the right traffic on the link is the job of the core routers, usually not fixed switches.
That's it for now, any songs I should also think about including into the Data Center QoS Playlist?
dg
Jul/098
HP versus Cisco: to tag VM’s or not to tag VM’s
Tag, you're it!
Recently there has been some eloquent flaming back and forth between Cisco and HP over the VN-Tag, of course I have an opinion and figured I would vocalize it. Scott Lowe has a good piece on this as well, focused more broadly on the implications to the unified computing system.
First off, I do not think there is a lot of innovation that comes directly out of the standards bodies. However, i firmly believe that in today's mature networking market in order for a technology to get a decent traction and following it must at least be inserted into the standards process and be on a trajectory towards being multi-vendor and open/interoperable.
Secondly, I believe that innovation should be rewarded. "To the innovator go the spoils" I say. Innovation is risky, there should be a bit of light at the end of the tunnel. I am not-so-subtly reminded of a conversation with about 20 customers I led a few months back. I was getting a lot of pressure from a university customer to stop any development on anything that was not an industry standard- the gentleman from a large manufacturing company interrupted him and said, "I don't care what standard they support, as long as they solve business problems for me I will vote with my wallet. My CIO doesn't care if its PAGP or LACP, he cares that the network runs."
Lastly, and somewhat controversially, I think there are enough tagging formats out there already, and worse: most of them have no interoperability plan or architectural tie-in with each other.
Let's look at VN-Tag with these three lenses now....
1) VN-Tag was jointly developed by Cisco and VMWare to address a problem their customers were having: they could not bind a policy to a VM and have that policy move with the VM in a DRS or VMotion environment. They also felt that traffic could go from one VM to another, bypassing any network policy for governance or regulatory compliance and thus have a tail-end/hop-off type of attack possibility for VMs on the same physical host.
2) It was submitted to the IEEE, but is not a standard yet, thus to be binary it is 'proprietary' although it seems the companies are not holding onto the IP specifically, they just want to execute on a time-to-market advantage. (this is no worse and the ongoing CEE vs. DCE debate (note: there both are proprietary... DCB is the IEEE standard))
3) It is 'yet another' tagging format. If you trust that MAC addresses will not change dynamically the same problem-set could have been solved by binding network policy to the MAC address of a host.
Was VN-Tag necessary? maybe...maybe not. Personally, I think many of the same problems could have been solved if the MAC address was used to instantiate policy. There is a legitimate concern that the MAC address could be spoofed, but then again so could a multi-byte tag structure too unless it has signing/authentication/etc.
Is it proprietary? Yes. Although all indications are Cisco and VMWare are working to shape an industry 'de jure' standard and are trying to gain a time to market advantage over merchant silicon based players. (I would argue that innovation should be rewarded so a time to market advantage in silicon is not out of the question and probably shouldn't be demonized).
Is it well implemented? Here is the rub of the whole thing. Implemented broadly this is a promising capability for a network to have. VM's are, after all, the building block of many leading edge new data centers. However, VN-Tagging does not seem to be broadly embraced across the portfolio of products in the data center. At least I can see no indications of shipping products or announcements of how this capability is going to be brought into the security products, application networking products, routing products, rest of the Nexus line, etc. Broadly implemented in a coordinated fashion- this would be a powerful capability. Sporadically implemented in one or two products will lead to little impact.
This will probably get flamed a bit, so am finding the nearest asbestos store...dg
Jul/0914
Hello Gorgeous! Best of Networking Industrial Design
This is not networking equipment either...
You could also title this one 'Things I'd like to Change Part 2/N'
I was reading NetworkWorld today, (now please don't ask me why I am sitting in Rio de Janeiro reading NetworkWorld (no offense John Gallant, Jim Duffy, Brad Reese, etc) It is just that most people do not usually associate beaches in Brazil with blogging and reading NetworkWorld, scandalous I know...) and anyhow, I was reading NetworkWorld today and I saw that the top read article was title '15 of the Greatest Tech Designs Ever'. I was intrigued!
So I click through item, by item, by item. I saw Aibo's and headphones, and phones and Blu-Ray players. One question occurred to me - "Where are the NETWORK devices guys?" The closest I saw was a malformed toaster-oven from 3Com named Audrey that suffered a premature demise in the dot com bust. This got me wondering - what are the best designed NETWORK devices? You know, Switches, Routers, Firewalls, Load Balancers, Optical Transport, WiFi Access Points, etc! You know, the good stuff!!!!
Now, I have my own opinions and will kick off the comments with a few items that I like, but I would really like to know what the best designed network products are. One caveat - let's not focus 'under the hood'. I don't care for the purposes of this discussion thread about what chipset it used, whether it actually even came close to the performance numbers the vendors touted, or whether it had AC or DC power supplies. I know this stuff all matters, but I am being exceedingly shallow- I just want to focus on the aesthetics, physical functionality, the design, and how usable the product is. Give some reasons you like it! Also, what are the worst? What lessons can be learned there about how NOT to design a product?
dg
default gateway
- Vendor Math September 18, 2009
- Implications of Virtualization and Cloud August 19, 2009
- Virtualization's Impact on Networks August 6, 2009
- Brad Reese, PR's Worst Nightmare August 5, 2009
- Hello World, and Random Career Thoughts August 4, 2009