State Verses Stretch

Network design is, as all things, a matter of choosing tradeoffs –there is no such thing as a free lunch! One of the tradeoffs we deal with all the time is state verses stretch. But while running through the CCDE slides at Cisco Live today, I had a lot of questions about what state and stretch really mean.

Stretch, quite simply, is the difference between the optimum path through the network (for any pair of hosts), and the actual path through the network. For instance, if the shortest actual path available is 2 hops, but traffic is actually flowing along a 3 hop path, the stretch is 1. Why should we ever have stretch in a network? It seems like you’d just never, ever, want stretch, because stretch always represents suboptimal use of available resources.

Because one of other fundamental concepts of network design is the use of information hiding to break up failure domains. Hierarchical network design, in fact, is the intentional use of aggregation to reduce the state –the routing table size, in most cases– in the control plane, so that changes in one area of the network don’t cause changes in the routing table halfway around the world. How does this relate to stretch?

Any time you hide state you increase stretch.

This might not be obvious in all networks –specifically, any time 100% of your traffic flows north/south, decreasing state will not impact stretch. But if you have a combination of north/south and east/west traffic, aggregation –reducing state– will always cause traffic to take a suboptimal path through the network –increased stretch.

Spanning tree is a perfect example of running to one extreme of the state/stretch tradeoff. Spanning tree reduces the state by forcing all traffic along a single tree in the network, and blocking links that don’t belong to that tree. Control plane state is absolutely minimized at the cost of increasing the stretch through the network to the maximum possible –to the point that we often design network topologies around the elimination of links not used on the single tree. TRILL and other fabric solutions break the single tree by injecting more state into the network. Another example is virtualization –splitting traffic off into a separate virtual topology removes the state of large numbers of destinations reachable through the physical network topology, at the cost of setting the stretch for those destinations to infinite (they become unreachable).

The state/stretch tradeoff is a useful tool, a useful paradigm to understand and describe the tradeoff between hiding information and optimal traffic flow through the network.

 

About Russ White

Russ White is a Network Architect who's currently looking for a new challenge. He's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about, or don't really care about. If you want letters, well... BSIT/MSIT (Capella University), CCIE #2635, CCDE 2007:001, CCAr. So there.

  • http://twitter.com/nkrypted Brandon Mangold

    It was nice to meet you today and thank you for sharing your insights by blogging on Packet Pushers.

    • riw777

      Thanks! hopefully, I’ll be able to keep up a solid pace of blogging here. I think PP has a great future…

  • Jeremy Stretch

    The title of this post popped up in my RSS reader and for a second I thought I was in some deep trouble…

    • http://twitter.com/nkrypted Brandon Mangold

      Ha, I can image so.

  • Jsicuran

    Good article Russ, another analogy, an oldie but goldie, can be found in Doyle’s Routing TCP/IP vol  II.  Under the BGP section regarding route aggregation, “the good the bad the ugly”. Basically visibility detail vs. ripple and pain being felt. Application dependent of course at times but still for its time a good reference.

    • riw777

      Yes –that’s the same problem, expressed in a different way. I plan on going through a few of these, because I think we focus so much on the physical hardware that we often forget these these theoretical constructs and design paradigms.

  • riw777

    Thanks, Petri –I was sitting in the back of the CCDE Techtorial writing this, so I didn’t spend a lot of time looking up references. Kriukov is definitely the one to turn to for a good description of the paradigm.

  • http://www.facebook.com/profile.php?id=1308904376 Mustafa Bayramov

    draft-ietf-grow-simple-va address some of the current FIB scalability problem but it more optimization then anything else