Braess’ Paradox in OSS

Braess’s paradox is a proposed explanation for why a seeming improvement to a road network can impede traffic through it. It was exposed in 1968 by mathematician Dietrich Braess who noticed that adding a road to a congested road traffic network could increase overall journey time, and has been used to explain incidences of improved traffic flow when existing major roads are closed. The paradox may have analogues in electrical power grids and biological systems. It has been suggested that, in theory, the improvement of a malfunctioning network could be accomplished by removing certain parts of it.
Wikipedia entry.

Braess’ Paradox is a fascinating concept. It represents ruthless simplification – the ability to remove infrastructure yet gain better results. I see this as having at least two applications in the world of OSS:

  • Network reductionOSS have a view of the whole network so they have the ability to run network simulations to check whether the removal of certain network links will likely improve overall performance (in working and protect / failover modes during busy hour modelling). Taking it a step further, the OSS could even turn off certain links to test whether the simulation mimics reality, knowing that it can turn the links back on (and initiate any failbacks) if the real network response doesn’t match the expected / simulated results
  • System reduction – as articulated in “subtraction projects” and “ruthless simplification,” the operational systems (and everything upstream of them, all the way up to product offerings) can be systematically pruned to evaluate what impact it will have on organisational productivity. This requires a company-wide look into Braess’ Paradox

Both of these can already be facilitated by Decision Support Systems to supplement other OSS tools.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

4 thoughts on “Braess’ Paradox in OSS

  1. Brilliant! Now I want to go back 4 years and propose a new network optimization product. “Hey we can reduce your network and your cost and increase performance”. Great RoI!

    I’m sure this paradox is pretty common in IP networks where network ‘design’ has only the fairly coarse tools of OSPF link weighting and LSP super highways – Both of which equate to building a new road and stuff all the traffic down it no matter what.

    Apart from OSS doing the analysis, we’d then need a real-time-ish means of balancing traffic across the network – As that seems to be the crux of it – Having traffic flow for the common good rather than an individual car’s/packet’s path of least risk.

  2. Hi James,
    Great points. You’re right that traffic engineering (TE) in an OSS has great potential. Unfortunately I’ve only developed a couple of TE approaches in OSS because it has tended to be done down at the EMS/NMS levels of the stack. I wasn’t aware of Braess’ Paradox at the time of those projects so I didn’t build it into my TE algorithms back then…. Next time 🙂
    PS. Don’t worry about the 4 years back, how about building one now? As the Chinese Proverb states, “The best time to plant a tree was 20 years ago. The second best time is now.” 😉

  3. Could one link this to SDN? The video seems to infer that distributed control and decision making (by individual drivers) works fine in networks that are not heavily meshed, but that a heavily meshed network benefits from centralized control.

  4. Hi Roland,
    I love the way you’re thinking here.
    I’ve never heard of anyone considering Braess’ Paradox in the context of SDN (vs distributed IP networks) so I can’t say for sure, but it does seem to be a very well considered argument. It does seem logical to me too that centralised routing control should indeed remove the condition that allows distributed decision making to introduce the Braess Paradox, but I guess it all depends on whether the centralised routing algorithms are taking this into account. I also wonder whether there would still be the potential for it occurring with new PoI links in a broader network where SDN domains are federated?
    I’d love to hear the thoughts of any SDN routing experts out there as to whether Braess’ Paradox could still exist in an SDN environment?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.