Slashdot Mirror


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.

12 of 48 comments (clear)

  1. Hard to reduce complexity by sideslash · · Score: 4, Interesting

    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.

    1. Re:Hard to reduce complexity by Z00L00K · · Score: 2

      Don't forget that the type of traffic that is passed over the net also is a factor involved.

      It's possible to have 1000 users on a 10Mbps network if the only traffic they have is text terminal traffic but you can completely saturate a Gbps network with a few users doing processing of video streams.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  2. I recall an experiment to do just that by i+kan+reed · · Score: 3, Funny

    It was a program by one Robert Tappan Morris, as I recall.

    That didn't go over so well with everyone.

    1. Re:I recall an experiment to do just that by stiggle · · Score: 2

      Morris only experimented over TCPIP on unix systems running finger. He bypassed/ignored X.25 and other non TCPIP networks.

  3. Re:Plot traffic, establish a norm, compare history by ender- · · Score: 5, Insightful

    I think they're trying to do something a bit more detailed and theoretical than seeing how much traffic is going through a given interface...

  4. Re:Plot traffic, establish a norm, compare history by bengoerz · · Score: 5, Insightful

    Best way I've found to measure growth is to have a running history of traffic on each router. You don't need a $billion to do it. There are some decent enough FOSS tools out there to do it. MRTG or Cacti will work nicely and integrate with SNMP.

    For a smaller network, you could run a span port and graph your own data with a shell script, or hook up NTOP. which will give you real-time views of traffic but you would need to implement something to save those reports daily.

    You suggest some good tools, but they primarily measure network utilization rather than capacity. The question isn't "how much data is my network handling now" but "how much data could my network handle at peak"?

  5. Applications.. by David_Hart · · Score: 2

    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.

    One could argue that this could be used, for example, in a mesh MPLS cloud when a path through a specific hop (i.e. office) may be more efficient, because of network conditions, than going straight to the end node. However, this would require each node to have enough bandwidth to support the added traffic, over and above the normal location traffic. Which means requiring a larger budget for bandwidth that is only used in certain degraded conditions.

    Basically, it's a study of the Internet and, in my opinion, would have little application in a corporate LAN. The reason why I say this is because a Corporate LAN is more deterministic in path selection and is limited by cost.

    1. Re:Applications.. by vlm · · Score: 2, Interesting

      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.

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
  6. Re:Plot traffic, establish a norm, compare history by Ihmhi · · Score: 3, Funny

    Hook up a BitTorrent seedbox to the live Internet. You'll find out the maximum capacity pretty quickly.

  7. I did my master work in Network Capacity Planning by mordred99 · · Score: 5, Interesting

    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.

  8. Re:Limiting factor by Anonymous Coward · · Score: 3, Insightful

    By channel you mean "a network of noisy, independent, memoryless point-to-point channels"? The result in the paper says that
    such channel can be seen as a network of error free channels. On such network it is already known that network coding delivers
    a better performance than routing alone. (see the butterfly network example in https://en.wikipedia.org/wiki/Network_coding)

  9. Re:Why read your own article? by camperdave · · Score: 4, Funny

    ... computing the net resistance between 2 adjacent nodes on an infinite grid of 1 ohm resistors.

    You're just trying to get someone to post a link to the XKCD comic about nerdsniping. Well, it won't work.

    --
    When our name is on the back of your car, we're behind you all the way!