Calculating Total Network Capacity

New submitter slashbill writes "MIT's working on a way to measure network capacity. Seems no one really knows how much data their network can handle. Makes you wonder about how then do you calculate expense when building out capacity? From the article: 'Recently, one of the most intriguing developments in information theory has been a different kind of coding, called network coding, in which the question is how to encode information in order to maximize the capacity of a network as a whole. For information theorists, it was natural to ask how these two types of coding might be combined: If you want to both minimize error and maximize capacity, which kind of coding do you apply where, and when do you do the decoding?'" This is a synopsis of the first of two papers on the topic.

Hard to reduce complexity

[sideslash]

Didn't read the article, but I imagine that part of the difficulty is that network capacity isn't reducible to an individual scalar number, but rather looks like an N-dimensional graph. There are many points of failure and bottleneck depending on how each node behaves relative to other nodes.

I did my master work in Network Capacity Planning

[mordred99]

and the answer is "It Depends". The traffic, the routing, the overall bandwidth (you never get 100% usage) all have factors. The easiest way is to look at your pipes (each segment is separate) and see the error rates, back pressure (QOS, Ethernet, etc.), average throughput breakdown (types of traffic), and usage percentage. This will give you a clear picture. Take those numbers and watch them over time, and you will get a clear picture of your network.

You cannot answer a question such as this truthfully if you take one sample size, and assume that is fact. Many sample sizes make the true picture, and then you can also see trends to determine if things are getting out of control.

Re:Applications..

[vlm]

It sounds like they are studying the effect of having intelligent nodes in a network that not just forwards a packet, but also performs error correction, has some basic path intelligence, and sends the packet out multiple interfaces. The end node then receives these hybrid packets from different directions, some coming faster, some later, developing a map with the most efficient path.

The eternal wheel of IT endlessly rotates old ideas into newness. Interpret that as either my mostly new source route bridged SDLC mainframe network in the early 90s or my decaying decrepit X.25 network in the late 90s. I played with some stuff like that using AX.25 as the phy layer around 1990. We had tools and papers and equations back then to analyze.

Did you know you can make networks like that oscillate if you're not careful? We also collapsed a few accidentally by packet flooding beyond a certain hard threshold. Also the behavior of an intelligent network of identical clones is easy to predict and damn near impossible if some of the clones are different in even the slightest way, not just different mfgr but even minor software revisions causing different bugs, but even improvements making some faster than others or removing bugs from some devices can cause collapse. Another fun one is trying to give a holographic picture of the routing to all nodes ends up in 90s era OSPF collapse when there's just too dang much in one area for it to ever converge. Another fun situation is when processing the routing data takes longer than sending the routing data (more or less similar to the previously mentioned OSPF collapse scenario)

Everything old, is new again... Personally I'm waiting for something like 3725 communication controllers to come back in vogue, kinda like akamai or anycast root DNS servers but did distributed back end also, not just front end caching.... a cool and weird tech.