Practical Technology

for practical people.

February 19, 2014
by sjvn01
0 comments

OpenDaylight: Open Source Programming to the Software-Defined Network

If you follow networking vendors, you know they get along with one another about as well as a dog whose tail has just been pulled and a cat who’s had a bucket of water dumped on him. That’s why it was more than a little surprising when the Linux Foundation managed to get Brocade, Cisco, Juniper, and many other network powers on the same page when it came to software-defined networking (SDN). More surprising still, it got them to work on SDN together in an open source project: OpenDaylight.

To understand why such long time corporate enemies, as well as such unlikely allies as Red Hat and Microsoft, all joined forces to back SDN in OpenDaylight, you first need to know a little about SDN.

In the simplest terms, SDN brings software programmability to networks. This can be done with the OpenFlow protocol, but other protocols can be used. With these protocols, you use SDN to centrally set up, manage, and monitor your network’s routers and switches. This enables network administrators to create efficient virtual networks that are independent from physical networks.

The result is less-rigid datacenter networks. With the rise of the cloud, datacenters need their networks to be as flexible as their virtual machines. When customers bring up and down thousands of server instances in a day, not being able to connect one bank of servers to another efficiently because switches aren’t connected properly is unacceptable.

The companies behind OpenDaylight can read the IT prophecy tea leaves better than most. They realized that trying to come up with an SDN standard would takes years. Time is precious in a world where efficient cloud applications are becoming ever more important.

The erstwhile competitors also figured out that trying that the tried-and-true method of locking customers into a single vendor’s technology was unlikely to work. Cost-conscious companies are wary of vendor lock-in “deals.”

Even Microsoft, yes Microsoft, is getting it. When I spoke recently with Rajeev Nagar, who oversees Microsoft’s Windows Datacenter Networking & Platforms, he told me that Microsoft sees OpenDaylight as an example of “everyone working together in a virtuous cycle in which both vendors and end-users will benefit.”

So it was that major rivals decided to try creating a set of open source programs, Project Daylight, to deliver SDN to customers. Good news: It’s working.

Today, OpenDaylight is an open source platform for network programmability to enable SDN and create a solid foundation for Network Functions Virtualization (NFV) for networks at any size and scale. OpenDaylight software is a combination of components including a fully pluggable controller, interfaces, protocol plug-ins, and applications. The Northbound (programmatic) and Southbound (implementation) interfaces are meant to be clearly defined and documented APIs for network applications.

At the first OpenDaylight Summit, OpenDaylight’s founders said you should judge their results not by their words but by their code. Their code is impressive.

When OpenDaylight started in April 2013, it only had two open source projects. Now, it has sixteen. By Ohloh‘s count, the Black Duck Software site that tracks open source development, OpenDaylight now has more than a million lines of code. Of those, 461,000 lines of code are in Java, with C++ in second place with 292,000 lines.

OpenDaylight also has 154 developers. “This is one of the largest open source teams in the world, and is in the top 2% of all project teams on Ohloh,” said the Ohloh representative at the conference.

This compares well to far older, popular projects, said Anees Shaikh, formerly the leader of an IBM research group devoted to SDN and now a Google network architect, in a speech during the conference. For comparison, OpenStack has 1.67 million lines of code and 1,974 contributors; Apache CloudStack has 1.5 million lines of code and 250 contributors; and Eclipse has 2.67 million lines of code and 404 developers.

OpenDaylight’s already much larger than some other open source SDN projects such as Apache and Big Switch’s Floodlight OpenFlow controller, which has 97 thousand lines of code and 32 contributors. It’s comparable to Juniper’s Contrail Virtual Router and Contrail Controller with its combined 280 thousand lines of code and 69 developers. In short, OpenDaylight looks like it’s the leading open source SDN program.

OpenDaylight delivered its first developer release, Hydrogen, on February 5th, 2014. Hydrogen comes in three editions with the following features:

Base Edition:

  • Controller: A modular, extensible, scalable, and multi-protocol SDN controller based on OSGi.
  • OpenFlow Plug-in: Integration of OpenFlow protocol library in controller SAL (Service Abstraction Layer).
  • OpenFlow Protocol Library: OpenFlow 1.3 protocol library implementation.
  • OVSDB: Open vSwitch Database configuration and management protocol support, e.g. for Open vSwitch and other OVSDB servers.
  • YANG network data modeling tools: Java-based NETCONF and YANG tooling for OpenDaylight projects.

Virtualization Edition (includes Base Edition):

  • Affinity Metadata Service: APIs to express workload relationships and service levels.
  • Defense4All: Distributed Denial of Service (DDoS) detection and mitigation framework.
  • Open DOVE: Multi-tenant network virtualization based on overlays, including control plane and Open vSwitch-based data plane.
  • Virtual Tenant Network: Multi-tenant network virtualization application using OpenFlow.

Service Provider Edition (includes Base Edition):

  • Affinity Metadata Service: APIs to express workload relationships and service levels.
  • BGP-LS/PCEP: Support for traffic engineering with BGP-LS (BGP protocol library and topology model) and PCEP (path programming model).
  • Defense4All: DDoS detection and mitigation framework.
  • LISP Flow Mapping: Locator/identifier Separation Protocol plug-in, LISP mapping service (which can be used to implement virtual networks).
  • SNMP4SDN: Simple Network Management Protocol (SNMP) support and APIs to manage commodity Ethernet switches.

If you want to try it out for yourself, you can download prebuilt versions for RPM-based Linux distributions and ready-to-run Hydrogen OpenDaylight virtual machines for Fedora and Ubuntu. You can also work with OpenDaylight via the Ericsson-sponsored OpenDaylight testing lab in San Jose, CA.

Sound interesting to you? The project and its many vendors are looking for a few good programmers. Individual developers and technical writers can join the project via the developers page, while companies and organizations can join up from the Join page.

This is a project that I think has many aspects to it and great potential. If you’re serious about Java or C++ and ground-breaking network programming, I’d give it a try. I think you’ll be glad you did.

OpenDaylight: Open Source Programming to the Software-Defined Network was first published in Smart Bear.

February 18, 2014
by sjvn01
0 comments

You can keep using XP for another year, but do you really want to?

Computerworld – On April 8, Microsoft will pull the plug on Windows XP SP3 when it issues the final security patch for the 11-year-old operating system. So it’s high time to switch to Windows 7, right?

Probably. But it’s still going to be possible to hang on to XP for another year or so, and given the number of users still clinging to it, I’d guess a significant chunk will do so. But is that wise? Not really. Security risks are just going to keep mounting.

About those numbers: Net Applications states that in December, XP was still running on 29% of all desktop and laptop PCs. By some counts, XP still accounts for 32% of all Windows systems. That’s a heck of a lot of users.

You can keep using XP for another year, but do you really want to? More>

February 13, 2014
by sjvn01
0 comments

DDOS in 2014: The New Distributed Denial of Service Attacks and How to Fight Them

In early days of the Web, no one heard of a Distributed Denial of Service (DDoS) attack; malware came to us through other vectors. Then in early 2000, a series of them DDoS attacks knocked off the air such popular websites as Yahoo, CNN, and Amazon. Today, DDoS attacks are thicker than fleas on a hound-dog, and are more complex than ever. They can hit your sites and your customers’ sites from more angles and they can knock out a website for minutes or even days.

Continue Reading →

February 6, 2014
by sjvn01
0 comments

The Standards Wars and the Sausage Factory

Standards-making is like sausage making. You need it, but it’s ugly. Yet the standards process is the necessary evil behind every technology we rely on.

On August 6, 1890, William Kemmler became a victim of an early technology standards war.

In the 1880s, the technology standard war of the day was between Thomas Edison, the primary supporter of Direct Current (DC) for electrical transmission, and his arch-rival George Westinghouse, who supported Alternating Current (AC). In a last ditch effort to show why DC should become the standard, Edison killed animals with AC-powered devices. He then persuaded the State of New York that an AC-powered device, the electric chair, would be a more humane way to kill condemned prisoners, the first of which was Kemmler’s execution by electric chair.

It was all in vain. Alternating Current was the more efficient technology, and today our homes and offices are powered by it.

“The wonderful thing about standards is that there are so many of them to choose from.” –Admiral Grace Hopper.

Today no one dies from standard wars, not that you’d know it from Internet comments. But years, millions of dollars, and endless arguments are spent arguing about standards. The reason for our fights aren’t any different from those that drove Edison and Westinghouse: It’s all about who benefits – and profits – from a standard.

I know, I know. Some of you are convinced that standards are determined by which technology is “best.” You are ready to trot out examples such as the famed battles including VHS vs. Beta video tape, or WiMax vs. Long Term Evolution (LTE) for 4G. You will bring up more current wars, such as Google’s SPDY vs. Microsoft’s HTTP Speed+Mobility (over how to speed up HTTP data transmission) and the hot-blooded fist fights over what will replace the X window server system for the Unix and Linux graphics stacks: Red Hat and friends’ Wayland or Canonical/Ubuntu’s Mir.

Sometimes the standard is driven by technical excellence. Usually, it’s not.

First, as the famous xkcd cartoon indicates, there isn’t an ideal “best” standard that covers everyone’s use case. To borrow Eric S. Raymond’s open-source truism, “Every good work of software starts by scratching a developer’s personal itch.” Standards are the same. What scratches your developers’ use case does not (necessarily) scratch other developers’ itches.

So since everyone wants to have things his own way, we – as businesspeople and as technologists – attempt to find compromises through organizations such as the IEEE, IEC, ISO, and IEFT. In theory, these Standards Development Organizations (SDO), according to the IEEE Standards Association, “offer time-tested platforms, rules, governance, methodologies, and even facilitation services that objectively address the standards development life-cycle, and help facilitate the development, distribution, and maintenance of standards.”

Crash!

Excuse me. I had to pick myself up from the floor from laughing so hard. You see, as a journalist I’ve covered how standards are actually made. It’s a lot like sausage making: an ugly, painful process that you hope produces a product that everyone finds tasty.

Take, for example, the long hard road for the now-universal IEEE 802.11n Wi-Fi standard. There was nothing new about the multiple-in, multiple-out (MIMO) and channel-bonding techniques when companies start moving from 802.11g to 802.11n in 2003. Yet it wasn’t until 2009 that the standard became official.

What took so long? At the start, four major groups fought to decide 802.11n’s fate. Two groups’ proposals – one from Mitsubishi and Motorola, and another from Qualcomm – quickly lost support. The other Wi-Fi networking companies quickly united into two competing groups: Task Group ‘n’ Synchronization (TGn Sync), with Intel, Atheros, and Nortel; and World-Wide Spectrum Efficiency (WWiSE), led by Airgo Networks. Airgo also had the advantage of being first to deliver MIMO-capable chipsets.

This kind of consolidation between rival companies or groups in a standard war is common. Few technology companies can afford to set their own technology standards and expect to survive in the marketplace. (It can happen that way. For example, for decades Microsoft could set desktop standards by dint of “We set the standard since we own this market segment.”) Apple manages to get it own way of doing things – from Advanced Audio Coding (AAC) for music formats to Apple Thunderbolt for high-speed I/O – and get away with it because within the closed garden of the Apple development ecosystem there are no other competitors. Companies such as these are the exception to the rule, however.

However, the first-mover advantage often isn’t that important in the long run. AC came after DC, VHS came after Betamax, and RCA’s color-TV technology came long after CBS’s now forgotten color TV tech. That proved to be the case with Airgo’s Wi-Fi experience as well.

For two years, TGn Sync and WWiSE fought it out in standard committee meetings, with neither gaining the required 75% super-majority. In late 2005, it looked as though the two finally came to an agreement in the Enhanced Wireless Consortium. But while its allies might have been ready to throw in the towel, Airgo wasn’t.

Airgo fought on with such tactics as adding more than 12,000 comments (count them, twelve thousand) into the “final” 2005 Wi-Fi standard draft. As Bill McFarland, Atheros’ CTO and one of the draft’s editors and writers, said at the time, “There were a lot of duplicate comments, and three people filed comments for each and every blank line in the document. The physical process of dealing with so many comments is tedious and time-consuming.”

What finally brought this stage of the fight to an end was Qualcomm buying Airgo in December 2006. With Airgo’s management out of the picture by 2008, a true unified standard was ready for approval.

It would be smooth sailing from here right? Wrong.

Before the IEEE approves a given standard, everyone with a patent that touches that standard must sign a Letter of Agreement (LoA). The LoA states that the patent holder won’t sue anyone using its patent in a standard-compatible device. All it takes is one holdout: Commonwealth Scientific and Industrial Research Organization (CSIRO), an Australian government research group that held a patent that concerning the development of a wireless LAN, refused to sign the 802.11n LoA.

Cue a patent war. Apple, Dell, Microsoft, and 11 other companies tried to get CSIRO’s patents overturned. They failed. In April 2009, the tech giants and 802.11n companies surrendered and signed a patent agreement.

Finally, on September 11, 2009, 802.11n was approved. It had taken “only” six years. For a tech standard that everyone agreed was of vital importance.

The Standard Sausage Factory

Why did it take so long? Because the stakes are so high. As Carl Shapiro and Hal Varian wrote in The Art of Standards Wars, “The outcome of a standards war can determine the very survival of the companies involved.”

That’s why, ultimately, technology wars are not about technology. They are about business. Yes, you want a great technology that delivers the goods. But even if your tech is the best, if you can’t turn it into a standard, your innovation is unlikely to make it to market or succeed once it gets there.

Because the stakes are so high, the players can, and do, fight over every tiny issue. Each side seeks an advantage to make sure the resulting software or hardware works best with its “version” of the proposed standard. (For example, Microsoft wanted its finger in the XML pie, and used Microsoft Office formats to try to control it. So today we have two popular office document standards: Microsoft’s OpenXML and the ODF (Open Document Format). In the end, Microsoft finally, albeit very quietly, supports ODF.) The arguments are conducted in technical details, but money is the real driver.

These standards wars are painful, ugly, and can be incredibly petty from the outside looking in. Each participant wants the biggest possible pie.

These fights can be expensive in both engineering and legal costs, so some companies are moving away from standard wars. That’s supported by the realization of the virtue of compromises. That’s always been true: Sony and Phillips realized in 1982 that fighting over CD formats would do neither company any good.

More recently, we’ve been seeing an interesting blend of open-source development and standards. The Linux Foundation brought together fierce rivals to work together on technologies and standards in such consortiums as AllSeen Alliance for the Internet of thingsOpenBEL for open-source biological research; OpenDaylight, for almost all the Software-Defined Networking (SDN) companies; and Open Virtualization Alliance and Xen Project for KVM and Xen virtualization. Perhaps it’s the collaborative nature of open-source projects to which we can credit such successes. Facebook’s Open Compute Project brought open-source methodology to the data center. Apache continues to bring competitors’ projects such as Big Data’s Hadoop and Solr for search.

Open-source software and its business and development methodologies have shown that working together to create common software and standards is more affordable. In short, rather than take a chance on one small, late to market, and expensive pie, it’s better to get a share of one bigger, timely, and affordable pie.

Maybe, thanks to open source, the sausage days of standard making will be behind us. I hope so.

The Standards Wars and the Sausage Factory was first published in Smart Bear.

January 31, 2014
by sjvn01
0 comments

Told you so! Microsoft backs off on Metro

It looks like Microsoft has finally been hit by the clue stick of awful Windows 8.x sales often enough that it’s learned its lesson. Apparently, in the forthcoming Windows 8.1 update, the user interface (UI) formerly known as Metro will be bypassed, and users will default to starting in the defective, but better than nothing, desktop mode.

I’m going to tell you more about this potential, game-changing move, but first let me get this out: “HA! I told you so!”

Sorry about that. But ever since I started pointing out just how awful Metro was for the desktop, I’ve been buried by nasty emails from Microsoft shills telling me how wonderful Metro really was. Even as Windows 8’s sales slunk below Vista’s abysmal sales adoption numbers they kept screaming that Metro was great.

Told you so! Microsoft backs off on Metro. More>

January 16, 2014
by sjvn01
0 comments

Windows 9 in 2015: Desperation isn’t pretty

Seriously, Microsoft? You want to get Windows 9 — Windows freakin’ 9 — out in 2015?

I get that you want to distance yourself from the Windows 8.x train wreck. Who wouldn’t? But by upgrading Windows on a consumer pace, aren’t you taking a big chance that your enterprise customers will turn their backs on you? I mean, companies want desktop operating systems they can rely on for three to five years, not three to five seasons.

Let’s start with some fundamentals. As Paul Thurrott, senior technical analyst for Windows IT Pro and the boss of Paul Thurrott’s SuperSite for Windows, put it, “Windows 8 is tanking harder than Microsoft is comfortable discussing in public.” According to Thurrott, the free upgrade Windows 8.1, which offers major improvements over Windows 8, is installed on fewer than 25 million PCs. “That’s a disaster,” he wrote. Windows 9 (as it’s expected to be designated; Threshold is the code name for now) “will need to strike a better balance between meeting the needs of over a billion traditional PC users” and enticing users to a Windows experience on new types of personal computing devices. “In short, it needs to be everything that Windows 8 is not.”

Windows 9 in 2015: Desperation isn’t pretty. More>