Weird Teaching

Teaching with a mask on to students wearing masks is just downright weird. I can't hear students through their masks; I can't pronounce some words through my mask; and sometimes I look out at the class and see students with masks, sunglasses, and hats, and I have no idea who they are!

In my long (some would say overly long) career, I've had some challenging environments to teach in, though, so I think I can handle this new one!

Visa Training

Back in the 90s, I was once asked to teach a network troubleshooting class to the night shift at Visa (the credit card company). They wanted me to teach the IT help desk every night from midnight to 3 am. I asked them if this was really a good idea. They assured me it was. The first night went pretty well. The second night, at about 1 am, I looked out at the class, and every single student was sound asleep.

IBM Training

And then there was the time IBM asked me to teach a one-week Token Ring and Ethernet troubleshooting class. I asked them, "are you sure this is a good idea? Didn't you guys invent Token Ring?" They assured me it was a good idea. 

Sure enough, I arrived in lovely Fishkill, New York and went over the schedule with them (again), and they said "oh, we don't need the Token Ring day. Why don't you take Tuesday off and go sight-seeing." So I got paid to sight-see in lovely Fishkill. Granted, I did see some cool things. I visited FDR's home in Hyde Park, the Culinary Institute of America, Vassar College, etc.

"Main Street in Fishkill." Photo by Daniel Case, CC BY-SA 3.0, via Wikimedia Commons

US House of Representatives Training

Once I taught a class to the network engineers for the US House of Representatives. They forgot to book a training room. Your government at work, I guess. :-) They said, "no problem, we'll do it in the lab." They failed to tell me, however, that the lab was also where the line printers were. I taught the entire class as these huge, loud line printers printed multiple copies of some 500-page bill that the Representatives were working on.

Macintosh Software Development Training

And one more story: Early in my career, I taught a one-week Macintosh software development class at a resort in Mexico with a colleague. We said the class would start at 8:30 am. Not a single student showed up at 8:30 am. Finally, about 9:15 am the students started wandering in, looking bleary, drinking their coffee and smoking cigarettes. Around 1 pm they said it was siesta time and that we should start up again at 4 pm. 

I looked at my fellow instructor and saw that he was worried too. There was no way we could cover all the material with this schedule. But then the students assured us that they would work till 8 pm. And sure enough, they worked really hard from 4 pm till 8 pm. After that the evening was dedicated to eating, drinking "rum y cokes" and other adult beverages, and playing cards till 1 am. We instructors adapted quickly to this new fun schedule!

I Love You, IT Departments

Oops, one more story. I can't forget the time I was teaching a county IT department on May 5th, 2000, when the ILOVEYOUVIRUS broke out. One by one my students' beepers started going off and they left the room, looking panicked. Soon there was nobody left! 

Then one student came back in and said, "We better cancel class." Luckily it was the last day of class, a Friday afternoon of a 5-day class. The student added, "Would you like to help us troubleshoot? We've been hit by a massive virus!" The ILOVEYOU virus remains one of the farthest reaching ever. Tens of millions of computers around the world were affected. CNN had a good article about it 20 years after it struck. 

I Don't Love You, Covid!

So anyway, the show must go on, of course. But teaching with a mask? That is just weird. In fact, it's one of the weirdest experiences I've had in my long teaching career. Here's what I have to say to Covid: 

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.

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. 

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. :-) 

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. 

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: http://www.fryguy.net/2014/03/25/cisco-live-hats-over-the-years. 

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.