Jan/100
Homebrew Render-Farm. Frankly, ‘just cause’
Wire Frame of an Icon created in Rhinocerous and VRay
Ok, putting this in context- I wanted some new network icons. Somehow all the ones I used in the past were made by an art department I strangely do not have access to anymore, and I really don't want to have to pay an agency to make them for me. I could probably outsource somewhere, but don't want to have to explain what I want, so sometimes it is just easier to do it yourself. (and learn a few new things while you are at it.) Plus it was a good way to spend an evening...
So off I went. Using a 3d design program known as Rhinocerous, which is an insanely cool name (I wish I could name my products things like that... a new switch is the Raven 98000, and over here we have the Magpie 5600 connected to the Corpus Corax 11000. Ok, you get the drift, cooler names should be used in networking products, not just secret-decoder ring needing acronyms and SKUs limited to 17 characters.... (and who picked 17!)) Ok, off soapbox, don't expect this to change anywhere anytime soon.
So we have Rhino running, doing a bit of drawing, getting the shape right and such. Then you couple that with a ray-trace rendering app, in this case VRAY, for Rhino. You get a lot of choices about textures, lighting, etc frankly too many for a neophyte, but these are pretty powerful programs. This is where it gets fun though - there is an option in VRAY for 'distributed rendering'. Nerd alerts went off throughout my office as I madly scrambled around loading a VM with the VRay distributed rendering client onto every machine I could get my hands on. Old Mac laptops, an 8-Core MacPro, a 4-Core MacPro, even a 2-Core MacMini fell victim to loafing this intimidating piece of software. I then realized that I had some network issues to quickly patched through a few more Cat6 ports from the office to the wiring closet, locked the ports down at 1000-FULL and moved my IP Phone to a PoE port while I was at it...
Probably the coolest part was watching the MacPro spawn multiple execution threads which you cold see rendering in real time. Render times were cut down by about 70% from using just one machine.
Here you can see the active raytrace threads modeling different surface segments. I was playing with lines on the front to show hot-aisle cold-aisle airflow. FAIL. 
Lessons Learned
It wasn't all roses. A few things I learned and a few things I think the SW developers should focus on in future versions.
1) VRay and Rhinocerous both do not have native Mac versions yet. This is frustrating but you can work around it with VMware Fusion 3. They both worked pretty well through a VM on Windows XP. I am still not up to 7 being happy to have skipped Vista.
2) Since you are running it in a VM note this- On the station with Rhinocerous be sure to tweak your setting to as many CPU cores as you can. I set it up for 4 cores and 3-4Gb of DRAM on the VM. I need more RAM for this machine, it could easily be happy with 16Gb on the VM. I am looking forward to the native version.
3) On the distributed render farms you don't need a whole lot of memory as it seems mostly CPU intensive, at least for the way I was using it. I set mine at 512Mb of Dram and let the other machines continue their happy servitude streaming iTunes, serving photos, keeping my Drobo happy, and generally performing well. Even the Tweetdeck machine. On these and the master you will have to move the Network Interface Card settings from NAT (default) to Bridged. You will probably have to at least go to the console and do a 'ipconfig /release, ipconfig /renew' to ensure the adapter comes up and you are ont eh same LANs egment as teh physical hosts. I was not able to get it working with NAT. Also be sure to let the sockets through any host-stack firewalls, McAfee goofed me for a bit on this.
4) Room for improvement- a native MacOS client for Rhinocerous and for VRay would really help. But the way the developers have you add distributed render nodes is archaic. First on the node themselves it spawns a text window and doesn't provide any diagnostics, just a scrolling log when it gets a job.
b) VRay requires you put the IP address, hard coded, into the master machine of each client. Don't you think this would work much better integrated with Bonjour or something that enables auto-discovery of potential render-nodes.
c) Even smarter would be have the render nodes run as a reduced priority process in the taskbar. Then each machine in a studio could be helping any rendering via processor reclamation when not being dominated by the user.
d) I like the real-time display of the ray tracing going on, but put a report in their showing what system did what percentage of the work. This way I would now which ones to upgrade, find the bottlenecks, etc. A little diags would go a long way here.
e) Also when showing the list of the servers check availability and let me know BEFORE I start a render job.. novel.
Here you can see the finished object, ready for export to a PNG to plague PPT users everywhere... Not sure about my air inlets though...
In the end, it was fun, I will continue to use them, but there is some room to improve that would be really useful for someone like me and I imagine the IT staff at any design studio. Here's some shots of the finished products...
Here is a final of a 1RU switch, no air inlets or anything on the front. I like the raised blue arrow look a lot...
Nov/092
HP takes out 3Com- what is the next consolidation step?
HP-3Com - ushering a wave of tech consolidation?
People have been asking me for a while what the next 'shot' would be in the tech titan border-clash. Cisco entered the server market with UCS, and everyone was wondering what the response would be.
I didn't think 3com would be taken off the market this quickly, I figured everyone would wait a year or so to see if 3Com could be successful in breaking back into the global marketplace, outside of China, with their current and new product lines. HP, taking some risk in that department, made an aggressive move knowing that HP has the global footprint and 3com has strong roots in China that HP can leverage. I have to say it's an impressive bit of M&A.
But what is next?
The real question is how will others respond to this move. What will IBM do? What will Dell do? I have postulated for some time that we are in a phase of consolidation where the tech-titans, in order to have competitive portfolios, will acquire or build these capabilities.
Neither IBM, nor Dell have data center networking presence, both have partnerships with Juniper and with Brocade. A lot of people were betting on an HP-Brocade acquisition, as evidenced by the share price impact on Brocade today. And who can count out Oracle/Sun? They also do not have a networking footprint.
I think the major players will wait for a quarter or so, through the holiday season - evaluating their options and also seeing how HP rolls up the 3Com acquisition. If it creates competitive advantage for HP then IBM, Dell, and Oracle will follow in HP's footsteps. I can't say who will acquire who, but there is only a small universe of potential acquisition targets as well.
Does this spell the end of independent networking?
dg
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
Oct/094
ISR G2 – what I wish it was…
Cisco ISR G2 - the best a branch can get?
Cisco announced the new ISR line recently, a 3x performance improvement for the high-end moving up to ~150Mbps. But the question I have that has been lingering with me for a while is, "Why not use an x86 processor and a decent hypervisor with that?"
Crazy, I know, right? But with the current set of Intel Nehalem cores I can get several Gb/s of sustained throughput at varying packet sizes. So it's not like I have a data plane performance issue. You can even schedule the cores to provide additional protection for mission-critical control plane processes.
Regrettably, to me, this was not the direction taken with this line. Why do I think it would be cool? For several main reasons:
One thing you could do is run several VMs for integrating neat things like Call Managers and Network Analysis. Who needs a separate co-processor when you can cost-effectively get a CPU with more than enough horsepower and DRAM to run a variety of concurrent branch office workloads.
Control Plane Performance would be through the roof - so you can actually support the market that fiber to the home is creating for Gigabit Ethernet handoffs to the home and business. This is rapidly expanding and becoming a more and more popular handoff in dense urban environments.
Killer integration - run branch office apps, rin your own apps, run the routing protocol stacks, and have enough process and VM separation to guarantee performance and stability. But also you wouldn't have to do special versions of IP-PBX call management for the router- you could run the full-blown image right on it. Want WAN Optimization, load a VM. Same with Network Analysis, etc. At some point performance will peter out, but not too soon.
Sadly for me, this feels like an opportunity lost. But who knows - maybe they will pull a rabbit out of the hat with something like this someday.
dg
Oct/097
On Merchant Silicon and Lawnmowing
Custom or Merchant Silicon?
Hello there!
I've been on a bit of a vacation the past couple of weeks, so sorry for the slow-down in posting frequency. But now, I am back at my desk, with a decent speed Internet connection, and too many ideas on what to write about.
---------
Chance had it that today a friend of mine sent me an email reminding me of a blog post I wrote about a year and a half ago titled - 'On Merchant Silicon and Mowing my Yard.' It was a piece, purposefully a bit inflammatory, designed to have a bit of a go at the guys who were drawing some interesting comparisons to product lines I worked on.
As often happens, times change.
Reading this email which spoon-fed my prior writings back to me, I had to reflect a bit. Does merchant silicon matter? Is it a sell out? What creates customer value in a networking product? Is it the silicon, the software, the system as a whole, how it operates with other adjacent products, etc...
Realistically, to me, what most people seem to care about in a switch is that it works, at the performance rates necessary, and that the software is stable and has the features they need to accomplish the networking task at hand.
Inside this system there is a collection of silicon, some of which may be custom, some which comes from vendors other than the systems manufacturer. The PHYs are almost always 3rd party, the CPUs as well, most every part is always 'merchant silicon' except the switch fabric and the packet processor. These are custom in some switches, or merchant in others depending on that specific vendors goals for that particular product.
Ethernet continues to evolves and offers lots of opportunities for innovation and improvement - some of these will require new silicon, some will require new software. Using merchant silicon sometimes will affect a vendors ability to control the pace and order they bring features to market that require new silicon. However, with the breadth of silicon available in the market today there are several viable silicon choices.
Custom chips create their own set of challenges - most vendors doing their own chips actually do their own logic and rely on a third party to actually build the chips and fab them out, deal with the process challenges, etc. The vendors doing full custom take on a high cost burden up front and hope they get enough market traction to enable future R&D in their ASIC teams. In this period of compressed budgets these programs tend to be one of the first things to get financial focus. What do you think- is one better than the other, or is a healthy mix appropriate for our maturing industry?
P.S. Oh, and I outsourced yard mowing... too time consuming and others did a better job than I ever could.
Sep/093
The Year of 10Gb Ethernet?
When will 10Gb become 'default' on servers and data center hosts?
Since 2002 I have been attending trade-shows like Interop and answering the same question, "Is this the year of 10Gb Ethernet?"
I never really understood the question, but after perennially trying to answer, and usually being inaccurate to what that individual questioner wanted to hear I started thinking about this a lot more, at least so I could have a reasonably rehearsed answer. Running into Bruce Tolley from SolarFlare today, who hosted the panel I was on for at least the last couple of years, reminded me that we are still not quite in 'the year of 10GbE' so I started wondering why, and when it would be.
What's it going to take? What will it take for 10GbE to take off on the same growth pace that GbE had?
In no particular order, I will start with density. When I was first asked this in 2002 there was a single-port 10Gb Ethernet module shipping in the Catalyst 6500 and a roadmap to deliver a four-port module the next year. Density matters, and how dense a network device is can allow different use-cases for the nascent technology. I remember making a PowerPoint slide once that said essentially the following:
Single Port- nice demo
Two Ports- very expensive, nice for metro connections and dark-fiber long hauls
Four Ports- useful in Distribution to Core switch interconnection
Eight Ports- starts aggregating access layer switches
Sixteen Ports- a good density of campus wiring closet aggregation
Twenty-Four Ports- high performance server aggregation
Forty-Eight Ports- server aggregation
Not surprisingly as silicon densities increase, port densities tend to increase and costs can come down through volumes, value engineering, and better utilization of common equipment.
Orthogonal Upgrades. Not all budget cycles align. Sometimes you get budget for a server refresh, other times you have have budget for physical plant upgrades, and on others you have some room for new network equipment. Most 10Gb implementations today require 'symmetric upgrades' i.e. you have to uplift the cabling, the servers, and the switches all at the same time in a coordinated manner. This is usually a pretty big inhibitor. You need to be able to add switches that support past, present, and future speeds, on top of existing cable plant, then allow the servers to upgrade when their budget cycle allows and computational/transport demands require it.
Price. Yes, it always matters and many times it all comes down to price. Let's set a magic mark of 10% and 3-4x depending on how you look at this. It strikes me that when the price of a complete system (servers, NICs, cabling, switching) at speed X*10 is only 10% more than speed X the market moves pretty quickly to connecting the hosts at X*10. The other way to look at it is that when X*10 is 3-4x the price of X in a myopic pricing arrangement the technology also tends to rapidly shift.
In many cases across most major vendors you can get two or all three of the above today. The outlier for data center host conversion and 'cross-over' from GbE to 10GbE is 'LAN on Main Board'. When all other factors align this tends to come out, and then the world changes and in the span of 12-24 months the new transport closes the gap and then starts passing its predecessor.
When do I think we will see the transition and cross-over (caveat- in the data center. I see no current trajectory towards demands for 10GbE to the desktop or phone in a campus. For all that video is the vaunted next wave of upgrades I can put several HDTV signals over 100Mb pretty effectively and it won't make a dent in GbE much less 10Gb to the desktop) I saw some data recently showing 100% growth in 10Gb to the server quarter over quarter, although largely driven by HP Blades with their virtual connect and flex-10 offerings. Given this trajectory and the desire for the server manufacturers to have a compelling value proposition against HP and Cisco's UCS I would imagine they are rapidly moving to offering 100/1G/10G LOM offers on their bladed and stand-alone server systems over the next twelve months. Then we finally, after seven years of speculation, can have a 'Year of 10Gb.'
Aug/090
Will Virtualization Commoditize the Network and Threaten Network Vendors
This is Greg, he likes DNS and DHCP, IP Address Management, Fine Scotches, and Infrastructure 2.0
Just a quick link and shout-out to Greg Ness of Infoblox and Twitter fame for a nice piece in SeekingAlpha that just hit here.
As I have said often enough to have been quoted and mis-quoted a few times there is a potential value-shift in enterprise IT given the increased business value many enterprises are realizing from virtualization which in some cases takes the network for granted or as one rather esteemed company once stated, "just dumb plumbing."
I don't want to be just a dumb plumber, and I think there are a set of very strategic activities the networking vendors can do to ensure that the network continues to deliver high-value and business-relevant services that enable the networking team within IT to keep their place in the pecking order.
dg
Aug/095
a smaller company, a big job, a great opportunity
Chief Development Officer and Chairman, Andy Bechtolsheim
As many people guessed on the poll that was ran in early July on NetworkWorld I could not relax for too long -- today I started my new job as the vice president of marketing at Arista Networks. In the spirit of any good marketing executive I prepared a bit of a messaging doc and FAQ sheet to help me out in case I get questions by industry press, friends, my favorite bloggers, or the legions of Twitter-bots that follow my life's twists and turns...
Who is Arista?
Arista Networks is an early-stage start-up in Silicon Valley, re-launched in 2008, that is building networking platforms that enable our customers to build network systems optimized for high-performance computing, virtualization, and cloud deployments. Arista has a seasoned executive team including many industry veterans and successful entrepreneurs.
Why did I go to Arista?
Candidly I was not looking to go to a start-up when I left Cisco. I was expecting to land at a mid-cap since my friends tell me I am a bit of a 'big company guy'. I also had many friends in venture capital tell me that if I wanted to go that route it would be best to do an operating role as a senior executive at a start-up. This caused a bit of a quandary- I looked at many opportunities and it was amazing that, as I hoped, even in this market and economy there was an amazing amount of opportunities available. When I looked at Arista I found a few things very intriguing:
1) I knew the executive team very well having worked with Andy and Jayshree for over ten years each, there was a comfort level there.
2) I usually can pick apart many networking start-ups architectures for making a series of 'rookie moves' that they later have to throw more money into fixing - I didn't find any of those at Arista.
3) I was very excited about the opportunity to build a software company that delivers the software through a network hardware platform - the core intelligence is the operating system.
4) I didn't see much, if any, VC investment in IT infrastructure companies yet every time Ethernet went through a major speed/function transition there were always 2-3 mid-cap companies created.
Ok, so Arista makes a switch? I don't think I would be happy at a company that just had one or two product lines. Arista has a solid vision for changing the way IT infrastructure addresses the new wave of IT architectures coming to the forefront today - But also remember the core value is the operating system, it is much more than just the hardware.
Ok, so what's the real story? Let me give an example, I met with Ken Duda who leads the software development team. I mentioned some features that focused on network and IT operations and would make life simpler for the network team, add value to the network, and enable the network to be far more 'real time' provisioned at scale. I have been a public proponent of this particular capability for the last eight years, but was never able to get it shipping. I saw a demo of it last week.
I like designing products, I like watching the things I work with customers and build to solve their problems ship and become a reality.
What did I learn at Cisco that will help me at Arista? I have to say the last three years at Cisco were a phenomenal learning experience and veritable PhD in Marketing with great teachers like Paul McNab (perseverence, and technical marketing/solutions development - importance of verticals), Alan Cohen (thought leadership) Peter Linkin (rational, believable, and most importantly understandable messaging), Tom Keenan (operational management at scale, how to hire people that complement you but never compliment you), Hoff (hiring people WAY smarter than you are), and Anne Plese (social media maven, scary good marketing execution).
What will I do at Arista? I am a little daunted by the scope of the role. Things that I used to manage cross-functionally and always have a ready opinion about I now have to either manage, or do. I think I will be learning a lot over the next few years. A few things I want to do though are build great products, and use every available marketing vehicle to ensure our customers have visibility to them and most importantly use them successfully in the right places. Short version, and to quote the inimitable Justin Timberlake, 'We're bringing sexy back' - to switching.
This will probably be the last post I put up here about Arista and my role there. I intend to keep this blog as neutral as possible and have it reflect my own opinion while respecting my position at my employer.
dg
Aug/099
The Network’s Role in Cloud Computing
It's all happy up in the cloud, right?
For networking companies cloud computing could be the biggest boon or the biggest bane, or as is sometimes quoted - the road to (shareholder) hell is paved with good intentions.
Network companies have been relatively and somewhat strangely quiet about cloud computing. Sure we've seen some partnerships, some demonstrations, and a lot of rhetoric- but there really hasn't been a lot of action. There certainly has not been purposeful, planned, development. One of the reasons may be the school of thought that the network is an inherent beneficiary of cloud computing - certainly anything that spits more bits out and drives larger pipes is a win for networking, right? The darker side is that at scale cloud computing represents a fundamental shift in the balance of purchasing power and a massive consolidation of computing, and thus purchasing capability into a smaller number of larger companies.
We've already heard about search companies building their own servers and even rumors of them building their own networking equipment. When you have that much domain expertise consolidated and there is that degree of specificity about the features and capabilities required saving capex while lowering the power consumption reducing your overall operating costs against one of your biggest expense line-items is worth it to large enough providers. Plus many of these providers know exactly what features they do and do not need - and there is variability between providers based on their respective philosophies about redundancy, fault tolerance, accounting, traffic engineering, etc. Is this model for everyone? Certainly not. But for those with enough chutzpah, mass and the technical wherewithal, it seems to be working.
Now fast forward seven to ten years. (like when Bill Gates once famously proselytized a vision based on unlimited bandwidth and limitless computing power - what would you do?) Imagine 50% of the world's compute capacity is owned by five companies. The purchasing power would be immense, the value to a vendor of winning the deal is a make/break proposition to many start-ups and even mid-caps. The ability to squeeze margin out of the vendors and define the exact requirements for what needed to be built, unparalleled. High margins? Doubtful.
Where would the network be? Let's see, certainly my 'glass half full' self sees that there would be a large WAN opportunity and Internet core upgrades required to support the increase in mobile workloads and mix of elastic and real-time network traffic. Ideally there would be a way of consistently signaling a particular packet's requirement for real-time, lossless, or an elastic traffic profile across multiple network providers with some guarantee they adhere to the marking. Although with net-neutrality I doubt this will ever happen in any end-to-end consistent manner and the owners of the end-stations and clouds will over-provision capacity and use clever over-the-top mechanisms to solve this issue further reducing the carrier's value.
The main change for the network will be static and physical definitions of service bound to location shifting to much more dynamic addressing
and embracing workload mobility. The network needs to be able to move workloads to run on the server and in the location that can service that workloads performance and processing requirement in the most effective and efficient way possible. This will enable and drive demand for follow-the-sun, follow-the-kilowatt, and follow-the-tax-code portability and mobility requirements. This is not just moving a workload around the data center, this could be moving it from one continent to another, and not a one-time move, but a dynamic and elastic environment where resources are constantly being re-balanced to achieve operational efficiencies, meet customer SLAs, scale to add new customers or divest customers quickly, and ensure security/segmentation where appropriate.
As I have said before today's networks are not ready for this. The static addressing model is broken, the routing protocols are not designed for the scale or the change-rate, and the need for abstraction and management is different than any networking vendor has embraced yet.
Let's assume that the technical hurdles get solved, that really smart people who solved the addressing problems for mobile phone systems, local number portability, and global roaming can use some of the same principles and solve the issues around globalization of IP addressing, /32 host route mobility, and really large scale routing tables. Let's focus on what makes a networking system "cloud-ready" that is a bit more complicated than even these rather sizable network and routing architecture challenges- Religion. Politics. Business. Control.
Here's the big 'gap' in everyone's story. Right now each vendor views their own system at the core of this cloud. It's all about the network, server, VM, SAN, etc depending whom you are talking to. Everyone wants to take their castle and put it on a cloud, without giving the keys to above-said-castle to anyone else. This means a strong desire in every major player to keep business as usual and extend the current value proposition and operational models to the cloud as best possible, see what sticks, adjust, go from there.
I believe, depending how 'evolved' the segment is, this could be a major failure if the core capabilities of the technology are not designed around the principles needed in cloud environments: elasticity, self-provisioning, open APIs, programmability, trust, control, interoperability, etc.
Where are networking vendors failing and flailing? Largely around the management and configuration interfaces to their systems -- The CLI is dead to the new world order. Take every feature in a network operating system and write down the ones you use. Put them on individual note-cards on a desk and then put the ones that are machine-readable, software controlled/instantiated, centrally provisioned, and globally scalable in a box we call 'Cloud Ready' and put everything else in the 'Old World' box. If the Cloud Ready box is pretty empty, that vendor will be left with one thing to differentiate - PRICE.
Everything in the networking world is instantiated by a CLI. Every cloud operator I know wants a machine readable interface, they want their devices to plug into a common management framework, they want a single point of administration and control. For some this is home-grown, for some this will be VMware's vSphere, for others it may be another offering. This 'Cloud OS' does job macro-scheduling, enforces work flows, and provides elastic scaling and depends on machine readable interfaces into switches, routers, firewalls, servers, storage, and so on. It also will depend on consistency between managed devices - i.e. if stuff doesn't work identically between products the outliers are not likely to be adopted.
Many vendors are reticent to give their 'keys' to someone else's Cloud OS - i.e. if it can't be their own, they don't want to open the system up, to the operator this means now having to install multiple management systems when what they really want is one that can work with multiple vendors. The message I heard one cloud operator tell me was, "Be Open or Die."
Make the shift to building planned systems architectures, and intelligently using networking protocols to provide a consistent abstraction to a cloud OS, there is a chance to win big. Miss it, build fragmented systems with no management abstraction or not tie into the right eco-system of partners and risk rapid commoditization as the core value of your product can actually never be expressed to a customer/operator in a way they could use it. Unused features is simply higher cost with no incremental value.
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
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