Wednesday, January 16, 2019

20 Years of Network Design

Cover of Top-Down Network Design, 1st edition, 1999

Computer network design sure has changed in twenty years! Or has it? Although network technologies and applications have certainly changed, at least some of the classic principles of top-down design can still be applied today, whether your network is a set of virtual machines in the cloud or a set of Internet of Things devices. 

Twenty years ago this month, I published Top-Down Network Design with Cisco Press. Macmillan Technical Publishing actually held the 1999 copyright. I mention this because the book is not specific to Cisco-based designs. As I recall, Cisco was just starting Cisco Press in the late 90s, working with Macmillan (which became Pearson) and Cisco documentation gurus such as Kim Lew and others. Some of the books are not specific to Cisco technology, though. Good architecture is vendor-neutral and timeless.

Cisco Press was a terrific partner in the development of all three editions of the book. They did a great job with editing, marketing, distribution, and beautiful covers. They found and worked well with some terrific technical reviewers, including, but not limited to, Dr. Alex Cannara, Dave Jansson, Hank Mauldin, and Dr. Peter Welcher. In addition, Brett Bartow, John Kane, and Mary Beth Ray at Cisco Press deserve much credit for making my book and countless other Cisco Press books such a big success. 

Top-Down Network Design describes a top-down approach to network design that emphasizes the importance of analyzing business and technical goals before selecting hardware and software to build a network. The book presents a network design methodology that I developed based on my software development experience. "Don't start coding until you understand the problem you are trying to solve!" My professors and colleagues had drilled this axiom into me. I changed it to, "Don't start building a network until you have planned it out first."

Photo by J. Kelly Brito on Unsplash
Regardless of the type of network that you are working on, planning the design and configuration of the network benefits from the steps I developed for Top-Down Network Design:

  1. Analyze business goals
  2. Analyze technical goals
  3. Characterize the existing network
  4. Characterize network traffic
  5. Design a logical topology
  6. Design addressing and naming schemes
  7. Select bridging, switching, and routing protocols
  8. Develop plans for securing the network
  9. Develop plans for managing the network
  10. Test your design
  11. Optimize your design
  12. Document your design

Reading over the first edition (which I later updated to a 2nd and 3rd edition), I'm happy to see that a lot of the concepts remain important. I seem to have really enjoyed helping my readers learn network design terminology, such as scalability, availability, manageability, usability, adaptability, affordability, and other "abilities." All three editions also have good content about analyzing network performance goals and distinguishing requirements such as:

  • Capacity (bandwidth): The data-carrying capability of a circuit or network, measured in bits per second (bps)
  • Utilization: The percent of total available capacity in use
  • Optimum utilization: Maximum average utilization before the network is considered saturated
  • Throughput: Quantity of error-free data successfully transferred between nodes per unit of time, usually seconds
  • Offered load: Sum of all the data all network nodes have ready to send at a particular time
  • Accuracy: The amount of useful traffic that is correctly transmitted, relative to total traffic
  • Efficiency: How much effort is required to produce a certain amount of data throughput 
  • Delay (latency): Time between a frame being ready for transmission from a node and delivery of the frame elsewhere in the network
  • Delay variation: The amount of time average delay varies
  • Response time: The amount of time between a request for some network service and a response to the request 

Where the book hasn't aged well is when it recommends or discusses specific technologies. The first edition actually discusses ATM, Novell NetWare, and AppleTalk. :-) 
The book also probably has too much focus on carefully provisioning the right amount of bandwidth and using the bandwidth sparingly to avoid performance problems. These days, with the exception of wireless networks, we don't seem to worry about bandwidth. Perhaps we should, but with wired networks especially, it's very hard to use all the bandwidth we have, and with 802.11ac and 5G networks coming online, even wireless networks will often have sufficient bandwidth.

Also, with current network planning, we don't tend to characterize network traffic as much as we used to. Perhaps we should pay more attention to the distinctions between network traffic that requires low delay and jitter, for example, and network traffic that demands huge amounts of bandwidth. On the other hand, maybe throwing lots of bandwidth at the problem and spreading it across the globe results in less worry about network traffic characteristics.

Despite these caveats, the book has aged pretty well. The importance of planning is still as relevant as it was in 1999. Yes, we live in an agile world today where there's less focus on requirements analysis. Also, it's possible to simply start building a virtual network and to tinker with it till it works. Nonetheless, I think even virtual networks can benefit from less tinkering and more design. Don't forget the concepts in Top-Down Network Design. They can still help. 

And if you've been wondering, here's what I looked like in approximately 1999. I'm the one in red. I'm with my sister, nieces, and husband. I couldn't find any pictures where I'm not with family. That's a good thing.

Tuesday, June 19, 2018

Take an Ethics Class

Let's say you are a hot-shot programmer and you're excelling in your computer science classes at your university. Or maybe you're an up-and-coming network administrator and you're taking industry classes. Or maybe you're both, or all of the above! You're taking programming and networking classes in college and at work. Should you also take a class in ethics? YES! 

First, let's address the benefits you will gain from taking an ethics class. Thinking about ethics uses a different part of your brain than coding. Learning about ethical theories, ranging from Kantianism to Utilitarianism to Virtue Ethics, develops your conscience, not just your intellect. In ethics classes, you learn to slow down, to analyze scenarios where ethics play a role, and to apply ethical theories. You learn to contemplate, research, read philosophical treatises, and to discuss philosophy with other students. You are given an opportunity to develop your own ethical framework. 

An ethics class will make you a more rounded human being. Your brain will thank you. Your friends and colleagues will be glad that you took this class also. You are now more likable, able to communicate with people not like you, and more thoughtful. 

Second, let's talk about the benefits to society if you learn ethics. With a groundwork in ethics, you will be able to develop and deploy technology that benefits humans. Your work will not just bring you a high salary and make money for your corporation. Your work will help solve problems facing humans, animals, the planet, and the universe (if your technology is used for space travel).

I've encountered too many programmers and CS students who compartmentalize. They love coding and are good at it, but they assume that ethics is somebody else's job. No, you can't leave ethics to other people. Understanding and applying ethics is as much your job as coding is. 
  • What will you do when your boss asks you to deploy robots that will put hundreds of working-class wage-earners out of a job? 
  • What will you do when your fancy database is used to keep track of immigrant children who were taken away from their parents at the border? 
  • Have you thought about how your facial-recognition software can be used to breach people's privacy or to report to law enforcement the identity of protesters engaged in moral civil disobedience? 
  • Is the technology that you are developing making it easier for bullied students to feel isolated?
  • Could you develop technology that would help reduce gun violence? 
  • What are the ethics of companies using unbreakable encryption that can be used by both bad and good people? What is the balance between safety and privacy in these cases?
  • What are the ethics of hiring low-paid Chinese workers to manufacture digital products? 
  • Is the technology you are developing going to result in a net increase in the total good of affected parties? 
  • When artificial intelligence is as common as natural intelligence, will you be able to protect the rights of humans who haven't been able to afford to upgrade their brains?
  • In your day-to-day work, are you behaving ethically? Can you say that you "act only according to that maxim whereby you can at the same time will that it should become a universal law," as Kant would require? If everyone acted like you, would the workplace and society be a better or worse place? Is your behavior consistent with the actions of a virtuous person? 

It's really easy to get caught up solving technical problems. There's nothing better than writing elegant code that works and is finally debugged. But don't let that feeling be your only goal. Remember that humans will use your code and it could do harm or be used in harmful ways. Develop and apply your ethics at every point of your career. 

All students, regardless of their major, should think about how they will interact with others online, and they should learn their rights with regards to companies that deploy information technology, sometimes in unethical ways. For CS students, the thinking needs to go even deeper. 

If you are a Computer Science or Management Information Science student, thinking about the ethics associated with the mainstream use of robots, data mining, algorithms, artificial intelligence, website advertising, surveillance, online voting, etc., is actually more important than learning how to develop and deploy these technologies. Our future depends on you getting this right. 

Thursday, February 16, 2017

I Persisted!

I recently had a conversation with someone who didn't seem to understand why "She Persisted" rings so true for many of us. It's not really about Elizabeth Warren for us. It resonates with us because we think "I persisted" when we hear it.

In my case:

  • I persisted in the computer field even after it became mostly men.
  • I persisted despite being told that women shouldn't take jobs from men because women don’t need to support a family.
  • I persisted after being told I couldn't climb a crane to install software because someone might look up my dress. 
  • I persisted despite being told that women weren't good hires because they would get pregnant and leave.
  • I persisted after being told I didn’t need a job because my husband worked.  
  • I persisted despite watching men with fewer achievements get promoted instead of me. 
  • I persisted when I was told that the required qualifications for a job were qualifications that the recently-hired men for the same job did not have.
  • I persisted despite there being no women's bathroom where I worked! 
  • I persisted when male co-workers stole my source code and took credit for it.
  • I persisted when male co-workers broke my source code and didn’t take credit for it.
  • I persisted when my pay was less than men in the same job. 
  • I persisted as popular culture spread the myth that a computer expert has to look like Mark Zuckerberg. 
  • I persisted when I looked around the room at meetings or conferences and was unable to find another female face.
  • I persisted when my ideas at a meeting were rejected when the same ideas posed later by a man in the same meeting were accepted.
  • I persisted despite incessant comments about my clothes, hair, and jewelry. 
  • I persisted despite having my ass pinched at work.  
  • I persisted. :-) 

Tuesday, July 19, 2016

Network Disruption

Network Disruption. This sounds like a bad thing. We hear network disruption and we think service outage. At Cisco Live, I learned that disruption is a good thing! 

My two favorite sessions were: 

1. Network Transformation and Essential Skills for Next Generation Network Engineers [BRKSPG-1000], presented by Zahoor Khan and Imran Shahid, CCIE #11894 and #11893. (Yes they are just one number apart!) 

The speakers told us that everything about the network is changing -- its connectivity, service delivery, business model, architecture, etc. The speakers gently told senior-level engineers that they need to get off their bottoms and learn a huge amount of new stuff. (They said it much more eloquently.) This appealed to the Technical Instructor in me. 

2. Disrupt Yourself: Driving Corporate Innovation Through Personal Disruption [DEVNET-1219], presented by Whitney Johnson, @johnsonwhitney

One of the best parts of this presentation was that Whitney quoted Leo Tolstoy. She had a slide that included the quote above. This appealed to the English major in me.

The networking field is in the middle of a disruption that even Tolstoy would recognize for its revolutionary magnitude. Transformations include:

  • A change from Command Line Interface (CLI) to Application Programming Interface (API) 
  • Waterfall to agile methods
  • Purpose-built network devices to Network Function Virtualization
  • Closed systems to open systems
  • Manual to automated service chaining

Network engineers need to understand Software-Defined Networking and virtualization. They need to learn some programming and be fluent in Linux. They can no longer limit their skill set to one vendor's products. The speakers in BRKSPG-1000 gave us a laundry list of new technologies to learn that included these topics and many more. We should learn about OpenFlow, NETCONF, YANG, REST, Git, GitHub, DDPK, containers, Docker, Jenkins, Ansible, Puppet, etc., etc., etc. 

The speakers did a good job of making the learning sound exciting and not scary, at least not too scary. Learning is fun, they said. Also, they provided good advice on segmenting your learning and keeping your end goals in mind. 

Whitney Johnson's presentation was a perfect complement to the BRKSPG-1000 presentation about all the new technologies we need to learn. She recommended taking risks, but taking the right risks for you. She said to play to your distinctive strengths and to think about what makes you feel strong. Think about what skills have helped you survive in the past. Battle entitlement and step back to grow. 

Those of us who have been in the networking field a long time need to step back and learn an enormous amount of new information. We can't sit back and let the revolution wash over us. The disruption must come from within, as Tolstoy said. 

Friday, July 8, 2016

Cisco Live 2016!

I'm attending Cisco Live this year! This will be my first Cisco Live in five years, so I'm a little nervous. I have memories of being run down by hordes of young men swinging large backpacks. :-) But I also have memories of learning amazing new technologies, getting to know fellow networking nerds, and cool hats!

My first Cisco Live (Networkers) was in Palo Alto in 1995. I think that was the best hat year.*

The Session Catalog - Cisco Live US 2016 this year holds great promise!

I'm most looking forward to:

  • A new hat
  • Maroon 5
  • 13 Smart Ways to Program Your Cisco Network [BRKCRS-3114]
  • Containers on Routers and Switches: Run Your Apps and Tools Natively on Cisco Boxes [BRKSDN-2116]
  • OpenStack Deployment in the Enterprise and Service Provider [BRKDCT-2367]
  • Techniques of a Network Detective [BRKARC-2002]
  • Software Defined Network Automation Architectures [BRKDCT-2027]
  • Network Transformation and Essential Skills for Next Generation Network Engineers [BRKSPG-1000]
And of course this panel discussion (I'm on the panel): Build Your Personal Brand with Social Media. [CISSOL-1113]

*For a history of Cisco Live hats, see this article by Fryguy:

Friday, October 30, 2015

Thought Diversity Necessary for Formation of the Internet

Most of us in the computer field know that having a diverse workplace is important for making decisions on what products to develop and how to market them. But is diversity important for solving computer science and engineering problems? I say YES. Diversity helped form the modern networking field. Without diversity we would not have the Internet. 

The following parable is from a US point of view. Lots of work was done in Europe too, but that is for another post when I have more time. :-) 

In the early days of networking, most of the data communications experts were on the East Coast. So we had the mainframe which polled the slave terminals. We had RS-232 where terminals had to Request to Send (RTS) and get a Clear to Send (CTS) to communicate. 

We had error correction, network control, and time division multiplexing, where nodes waited their turn to talk. The algorithms were orderly, hierarchical, predictable, and unwieldy. 

With the culture changes of the 1970s and 1980s, ideas for algorithms were infused with more creativity, and Token Ring was invented. A ring sounds like something from The Hobbit, with liberal connotations, where all the nodes in a circle sing Kumbaya and use a token to determine who gets to speak. However, the algorithms were still mechanistic and militaristic. A network node seized the token in order to talk, and when the node was talking, every other node was required to be silent. An active and standby monitor were needed to oversee the operations. In bridged networks, nodes used source routing to dictate which path the data frames should take. 

The engineering was still being developed by the New Yorkers in suits and white shirts with pocket protectors. Token Ring was expensive and hard to troubleshoot, and it mimicked human communications found in hierarchical, autocratic, traditional societies.

Out on the West Coast and in Hawaii, on the other hand, we had the surfers and the hippies working on networking! In the 1970s, Bob Metcalfe flew to Hawaii and all hell broke loose. :-) 

Metcalfe's research on ALOHAnet, a wireless packet network that was developed by the University of Hawaii, led to the development of CSMA and Ethernet. With CSMA, nodes listen before they send, but if they don’t hear anything, they just send anyway. If multiple nodes sense that there’s quiet, they just go ahead and send, so there could be multiple nodes all talking at once. The nodes also listen while sending, and back off if necessary. It’s like a big party! Aloha! 

Ethernet was inexpensive, easy to set up, easy to troubleshoot (at least compared to Token Ring), and scalable. We still use it today with speeds up to 40 Gbps and 100 Gbps. The work of Radia Perlman on the Spanning Tree Protocol allowed robust bridged networks to dynamically form a spanning tree. Routing across Ethernet networks became possible with the invention of the Internet.

The Internet was developed by men and women, working on the West and East coast, and parts in-between. In the West, UCLA, UCSB, Stanford Research Institute, and the University of Utah first worked on ARPANET and then the Internet. On the East Coast, universities, the US federal government, and various companies helped develop protocols and algorithms. The developers decided to break up data into packets and to forgo traditional point-to-point telecomm links and circuits that needed to be set up in advance. This led to the NSFNET and then to the commercial Internet.

The Internet’s infrastructure was designed by engineers seeped in human communications styles very different from the hierarchical, autocratic, traditional styles mentioned earlier. 

If the development of network algorithms had been left only to the stuffy East Coasters with their crew cuts and slide rules, we wouldn’t be having this conversation today, on a public, gigantic Internet that is built on top of Ethernet and wireless technologies. 

Kitty Joyner, electrical engineer, at Langley in 1952.
It was the diversity of thinking that made modern networks possible. This isn't just some politically-correct maxim that applies only to product design and marketing. Diversity helped solve the engineering and computer science problems that made the Internet possible.

Wednesday, September 16, 2015

Top Ten Reasons Not to Publish Top Ten Women Lists

Sophie Germain by Auguste Eugene Leray
I'm guilty of making my own list of women who do great work in tech, but nonetheless there are at least 10 reasons we should stop publishing these "Top X Number of Women in Some STEM or Leadership Role" articles. And that is 10 decimal, not binary. :-)

  1. These lists are really getting old. Get creative. Stop copying everyone else.
  2. Lists of women in tech call attention to the shortage of women, and can be discouraging. 
  3. If we must make lists, let's make lists about top reasons to be a computer professional. Be encouraging! 
  4. An in-depth article about an ordinary woman and her work is more inspirational than a list of sound-bites about "top women."
  5. Lists are often not well-researched. A CEO with no engineering experience doesn't belong on a list of women engineers, for example. 
  6. Sometimes a woman in a "top 10 women" list was actually a man previously.
  7. It's 2015. Maybe it's time to talk about top performers in tech, regardless of gender.
  8. The actual work is being done by the thousands of women and men you left off your list. 
  9. Too often the list includes Ada LovelaceGrace Hopper, or Hedy Lamarr, whom we all love, but there are lots of living women in computing too. 
  10. When the tech workforce becomes more gender diverse, what are you going to do then? Top Sophie Germain prime number of women in tech? :-) 

p.s. To see my list of women in tech, go here