Archive for January, 2007

Why Diameter is almost irrelevant.

Thursday, January 25th, 2007

The IETF has spent a lot of time standardizing Diameter, which was supposed to be the next-generation successor to RADIUS. For a while, I was sure they were right. It turns out that Diameter doesn't matter as much as it could have.

For one, the Diameter base protocol is huge. The OpenDiameter people have been doing a good job of implementing it, but it's still much more complicated than RADIUS. That complexity has a cost: no one implements it.

Where a NAS vendor could spend a few days and have a pretty crufty (but working) RADIUS client implemented, the cost of implementing a Diameter client is much higher. As a result, almost no NAS vendors offer Diameter support. And since there's no support, there's no demand for it… which is a vicious circle.

The main benefits of Diameter are network features like guaranteed delivery, and automatic server discovery. Since the Radiator people cam up with RadSec, many of the benefits of Diameter can be obtained via RADIUS.

That effort hasn't (yet) translated into a RadSec implementation for FreeRADIUS, but it may happen soon. Once there are a few RADIUS implementations that usurp Diameter's functionality, there's even less reason to do a fork-lift upgrade to Diameter. In the end, I have a hard time seeing Diameter taking off anywhere, which makes it pretty much irrelevant for most people.

Efficiency takes work.

Saturday, January 20th, 2007

I came across the following paper recently. Titled in part One Size Fits All?, it shows how text processing benefits enormously from the use of specialized databases. They compare the performance of standard relational databases (RBMS) with the performance of systems designed to solve specific problems. They convincingly demonstrate that specialized systems can easily obtain two orders of magnitute better performance than RDBMS.

The reasons have to do with careful design, and choosing the right tool for the job. RDBMS are designed to do a number of things very well, but they're not spectacular at solving any one problem. If you want to quickly prototype a system, RDBMS are a good choice. But if you want a fast system, it's best to pay close attention to the design of the system.

The same design methods apply in the RADIUS space, too. It's easy to set up a RADIUS server that uses an SQL database to store authorization rules and accounting data. It's much more difficult to build a system that has the same functionality, but scales to 100 times the load of a “simple” design. But as my previous post showed, FreeRADIUS has (of course) no problem being part of such a system.