Week 5: Networking Part I

Because networking is a new topic for many of you, we’ve put together a short networking guide (PDF) to the very basics of networking. It should help de-mystify some of the vocabulary in the DARPA paper.

We also recommend the “How Does the Internet Work?” guide (a bit longer, but still short), which goes into more detail than ours. It’s from 2002, but the concepts still apply today.

If you are confused by any part of the DARPA paper, especially terminology, those two guides should be your first resources.

A bit of background on the paper itself:

This paper was written in 1988, before the Internet was commercialized. (Prior to commercialization, the NSF controlled most of the Internet primary routes that make up the Internet. In the early nineties, they sold their assets, which allowed private corporations to gain control. As a result—of this, and of a few other things—it became easier to do business on the Internet.)
The paper makes occasional reference to “TCP.” We will learn the details of TCP in a future lecture. For now, you only need to know that TCP provides reliable transport.

The paper starts by introducing the goals of the Internet’s architecture (Sections 1–3). It then dives into the details of some of these goals (Sections 4–7) before discussing implementation details and concluding.

As you read, you should think about:

Why did the Internet architects decide to divide TCP and IP into two separate protocols?
How do datagrams help the Internet achieve two of its goals: to connect existing networks and to survive transient failures?
If you could start from scratch, how would you redesign the Internet today? Would you keep the same principles but change their order? Would you use new principles?

Question for Recitation

Before you come to this recitation, write up (on paper) a brief answer to the following (really—we don’t need more than a couple sentences for each question).

Your answers to these questions should be in your own words, not direct quotations from the paper.

What were three of the most important goals of the early Internet?
How was it designed to meet those goals?
Why were those goals important (or, why does the author believe that those goals were important)?

As always, there are multiple correct answers for each of these questions.

Read “The Landmark Hierarchy: An New Hierarchy for Routing Very Large Networks (PDF)” by Paul Tsuchiya. This paper was written in 1988. In 1988, routing algorithms such as link-state and distance-vector (which you’ll see in the preceding lecture) already existed. The Internet also existed, and was beginning to grow, but was not the network it is today.

To help you as you read:

Section 2.1 gives an overview of Area Hierarchy, an existing system. The paper will continue to contrast landmark routing with area hierarchy.
Section 2.2 gives an overview of Landmark Hierarchy, the system that this paper is proposing. You should understand how routing and addressing work in this system. A good quick check is to look at Figure 4 and figure out what entries should be in Router g’s table (the text below Figure 4 will tell you the answer).
Section 3 gives a very brief overview of some of the other algorithms required for landmark routing.
Section 4 presents results on the performance of the landmark hierarchy, often in contrast to the area hierarchy. While reading this section, you should think about what aspects of their analysis are convincing (if any) and what aspects are not (if any).

As you read, think about the following:

How does the landmark hierarchy differ from the area hierarchy? Are there places where they perform similarly, or make similar tradeoffs?
The landmark hierarchy was not used on the Internet. Why do you think that is?

Questions for Recitation

Before you come to this recitation, write up (on paper) a brief answer to the following (really—we don’t need more than a couple sentences for each question).

Your answers to these questions should be in your own words, not direct quotations from the paper.

What problem(s) is the landmark hierarchy addressing?
How does it work?
Why do you think the landmark hierarchy wasn’t used on the Internet? (There are many reasons, but it is not because the ideas presented in the paper are inherently bad)

As always, there are multiple correct answers for each of these questions.

Welcome to Networking
- How networks work is a big part of systems.
- Network = source of failure for many systems. Why?
- Today: Intro to network / history of Internet. Look for common themes that you’ll see over and over.
- Don’t worry about details of specific protocols today; we’ll delve into those later on.
General Networks
- Model networks as graphs. Endpoints on outskirts, switches (a type of “middlebox”) in the middle. Edge = direct connection between two nodes (perhaps a wire, perhaps not).
- Problems:
  - Addressing
  - Naming
  - Routing
  - Transport
- For small networks:
  - Naming/addressing: Just assign each node a unique name.
  - Routing: How do nodes figure out how to get data to other nodes?
  - Transport: Lots of questions here. One problem to think about is reliability: What do we do when a packet gets dropped?
- In 6.033, we care mostly about the Internet. The Internet is not a “normal” network.
The Internet, Pre-1993
- Launch of Sputnik => creation of ARPA (now DARPA).
- 1970S: ARPAnet. Started small. Combined addressing and transport. Began to grow by connecting existing networks.
  - Using hosts.txt, distance-vector, sliding-window, etc.
- 1978: Decide to make the Internet flexible. Encourages a layered model. Typical model:
  
  7 [ Application ] - super high level
  5/6 [ Session/Presentation ]
  4 [ Transport ] - reliable (maybe) delivery
  3 [ Network - IP ] - addressing/routing
  2 [ Link ] - point-to-point links
  1 [ Physical ] - physical medium
- Often in 6.033 we care about the Application, Transport, Network, and link layers.
- Ideally, layering lets us swap out protocols.
- ~1983: TCP, provides reliable transport. Now apps don’t have to reimplement reliable delivery.
Growth => Change
- 1978-79: Link-state routing, EGP. More scalable routing.
- 1982: DNS. More scalable naming. Also enabled growth through distributed management.
Growth => Problems
- Mid 80s: Congestion collapse. So many packets in network, but none were useful. TCP added a congestion control mechanism (more on this next week).
  - Why add it to TCP, not as a separate layer? It was already hard to add a new layer, even in the 80s.
- Early 90s: Policy routing. Internet was beginning to be commercialized, parts of it didn’t want to provide transit to commercial transit. Policy routing (BGP) is a means to do this.
  - Notice: Commercialization is causing problems.
- Addressing. Assign addresses in chunks of different sizes. “Class B” chunks — 65K — are typically “just right”, and we ran out of those. The protocol CIDR was developed to divide these up.
  - Most interesting thing about CIDR: That it was possible to make this change at all. Changing addressing => changing switches. Happened because all switches were made by Cisco and forwarding was done in software.
The Internet, Post-1993
- 1993: Commercialization. Changes stopped. “New technologies essentially get deployed for reasons of fear or greed (PDF).”
Problems We Deal with Today
- DDoS: Send a lot of traffic to one machine to consume its resources. Hard to prevent. Internet wasn’t designed with accountability in mind.
- Security: Internet was not designed for security. DNS, BGP, etc., have no secure infrastructure.
- Mobility: No one every imagined this.
- Address Space Depletion: IPv4 -> IPv6.
- Congestion control: Should probably change given the changes we’ve seen in the Internet (more about this later).
So What’s New on the Internet?
- Lots. P2P, wireless, mobile, streaming, cloud computing, datacenter networks, security threats/defenses…
- Almost everything happens on the Internet today! Crazy.
- We expect to see continued changes: Massive growth, software-defined networks, sensors, robots, embedded devices, privacy, censorship.
Recurring Themes
- Layering and hierarchy (particularly hierarchy as a means of addressing scale).
- Scalability: If enforcing modularity was the theme of the first part of 6.033, scalability is the theme of the second part.
- Performance/efficiency: As the Internet grew, performance requirements informed its (re-)design.
- Diversity of Applications: As the Internet grew, more and more applications used it. These applications have different demands: Some care about throughput, some care about latency, some care about both, some need reliability, some don’t, etc. We have to build a network that works for all of them.
- Money: Because people pay to use the Internet, designing protocols can sometimes be trickier than it “should” be.
- End-to-end argument: What part of the network should implement what features (endpoints, switches, etc.)?

Introduction
- Today: Link-state and distance-vector routing.
- Neither of these routing protocols is used to route across the entire Internet; let’s find out why.
Routing Protocols in General
- Goal: For every node X, after the routing protocol is run, X’s routing table should contain a *minimum-cost route* to every other reachable node.
- Route vs. path:
  - Path = Full path packets will travel.
  - Route = First hop of that path. Node really only needs to know the first hop.
- Link costs:
  - Link costs can represent many things: Delay, congestion, etc. Sometimes all link costs are just 1, so that the min-cost paths are the paths with the fewest hops.
  - Link costs can change.
- Once a routing table is set up, when a switch gets a packet, it can check the packet header for the destination address, look that address up in its routing table, and add the packet to the queue for that outgoing link.
Distributed Routing Protocols
- Scale better than centralized ones.
- Three steps:
  - Nodes learn about their neighbors via the HELLO protocol.
  - Nodes learn about other reachable nodes via advertisements.
  - Nodes determine minimum-cost routes.
- All of these steps happen periodically, which lets routing protocols adapt as link costs change, as advertisements get lost, as links fail, as nodes fail, etc.
  - HELLO protocol lets nodes discover link/node failures.
Link-state Routing
- Main idea: Through advertisements, nodes disseminate information about the topology of the graph to all other nodes. Once all nodes have that information, they can run a shortest-path algorithm.
- Advertisement format: Each node’s advertisement is a list of its neighbors and its link costs to those neighbors.
- Each node sends advertisements to their neighbors, who forward to their neighbors, who forward to their neighbors, … I.e., advertisements are flooded.
- After flooding, each node should have a complete map of the network (except in the case of very specific, very rare sequences of advertisement loss). Nodes use this map to run Dijkstra’s shortest path algorithm.
  - Here’s one way to do Dijkstra’s algorithm, slightly different from the example I did in class (below, we assume that all nodes are initially known; you can make this a nodes-need-tobe-discovered based implementation with a few small changes).
  - In each step of Dijkstra’s algorithm, we keep track of W, the set of nodes we haven’t processed yet. Initially, W is all nodes in the network.
  - We also keep track of the current costs and routes to all of the nodes. Initially:
    routing_table [self] = Self; routing_table [anyone else] = ?
    cost_table [self] = 0; cost_table [anyone else] = infinity
  - u = the node in W we have the minimum cost to so far
  - Remove u from W
  - For every neighbor v of u:
    d = cost_table [u] + cost (u, v) if d < cost_table [v]   cost_table [v] = d   routing_table [v] = routing_table [u]
- Good things: Flooding makes link-state extremely robust to failure. Very unlikely that a node will miss so many advertisements that it has an incorrect view of the network.
- Bad thing: Overhead of flooding is overwhelming. N nodes, L links => ~2NL advertisements total.
Distance-vector Routing
- In link-state, nodes calculate full shortest paths. They really only need the route (first-hop) to a destination. Let’s exploit that.
- Advertisement format: Each node’s advertisement is a list of all the nodes it knows about, and its current costs to those nodes. Initially, this advertisement is just [(self, 0)].
- Nodes who receive an advertisement: Node X’s advertisement will be received only by its neighbors.
- Integrate step: When node X receives an advertisement from its neighbor Y, this advertisement will be a list of [(dst, cost)] pairs. Each cost represents Y’s cost to dst.
- If X is already using Y to get to dst, update the cost information (remember, costs can change!).
- If X is not already using Y to get to dst, see if Y could provide a better path; if so, update the routing and cost information.
- Good thing: Overhead is much better. N nodes, L links => 2L advertisements, not 2NL as in link-state.
- Bad thing: Counting to INFINITY
  - When a node A has no route to destination B, it will advertise a cost of INFINITY to B. A cost of INFINITY B is interpreted as there being no route to B. So INFINITY must be larger than the longest path in the network.
    - But because the order in which advertisements are sent matters, sometimes nodes can incorrectly think there’s a route when there isn’t one. This can last for up to INFINITY steps (see Lecture 9 slides (PDF))
    - Ironically, INFINITY is typically around 16 or 32.
Summary
- Link-state routing: Nice, easy to reason about failures, but overhead prevents it from scaling. In practice, good for MIT-sized networks.
- Distance-vector routing: Significantly less overhead, but harder to reason about failures. In practice, good for very small networks (where we can reason about properties of routing loops)
- As of right now, we can route data within MIT (via link-state), but not outside of MIT.

Browse Course Material

Course Info

Instructor

Departments

As Taught In

Level

Topics

Learning Resource Types

Computer System Engineering