3. Architectural Principles¶

Recall¶

Two canonical approaches to sharing 1. Reservations: end-hosts explicitly reserve BW when needed (e.g., aat the start of a flow) 2. Best-effort: just send data packets when you have them and hope for the best

Two canonical designs to implementing these approaches: 1. Reservations via circuit switching 2. Best-effort via packet switching

Circuit switching: idea is to reserve network capacity for all packets in a flow. Make sure you can send a packet through and establish a circuit

When it is done, then the circuit will teardown the reservations.

Packet switching: allocate resources to each packet independently

Circuit vs. Packet Switching: Which is Better?¶

What are the dimensions along which we should compare?

• As an abstraction to applications: it is useful for the application we are making?

• Efficiency (at scale): how well are you using network resrouces? Bandwidth is expensive...

• Handling failures (at scale): the system needs to be resilient to any failures

• Complexity of implementation (at scale): complicated usages are not really good

From an Application Viewpoint¶

• Circuits offer better application performance (reserved bandwidth)

• More predictable and understandable behavior (w/o failures)

• Also very intuitive abstraction in support of business models!

Which Makes More Efficient Use of Network Capacity?¶

Packet switching is typically more efficient, but it much better depends on the "burstiness" of the traffic sources. This is because packet switching implements statistical multiplexing at a finer granularity than circuit switching (packets vs. flows)

• Ex: 3 constant rate sources sharing a link. Total link bandwidth is 30 Mbps, and the demands are that each source needs a constant rate of 10Mbps. Circuit and packet switching give approximately the same result. Every source gets what they need, no wasted bandwidth, etc.

• Ex: Three bursty sources. For a reservation system:

and with best effort:

Smooth vs. Bursty Applications:

• Characterized by the ratio between an app's peak to average transmission rate

• Some apps have relatively small peak-to-average ratios. Voice might have a ratio of 3:1 or so

• Data applications tend to be rather bursty: E.g. ratios of 100 r greater are common when web browsing

• That is why the phone network used reservations and the Internet does not!

Other differences in efficiency:

• Circuit switching spends some time to setup/teardown circuits. Very inefficient when you don't have much data to send (short flows)

Handling Failures¶

For packet switching: If there is a failure, just send to another switch. The end host doesn't even need to know there was a failure. This is because decisions are made independent of each other. 1. Link goes down, then what? 2. Network must detect failure 3. Network recalculates routes: job of routing control plane 4. Endhosts and individual flows do nothing special: expect cop with the temporary loss of service

For circuit switching: if there is a failure, the network needs to recompute a new path. The endhost needs to send another reservation. The new reservation might not be able to accomodate the resources. We need to teardown, and then send a new reservation. It might not even work if they don't have the resources 1. Network must do all the things needed for packet switching 2. In addition, endhosts must detect failure, teardown old reservations, send a new reservation request 3. All impacted endhosts must do this, for each impacted flow 4. If milllions of flows were going through a switch, then millions of reservation requests are being simultaneously re-established

Complexity of Implementation¶

Recall reservations 1. Source sends a reservation request to destination 2. Every switch must say yes to establish a reservation. How do you know that the reservation went through? Extend the design so the switches know the reservation got through. 3. What happens if the reservation request is lost midway? Let's extend the implementation and create a timer that will know if the timer ran out of time, the reservation request was dropped. 4. What happens if the confirmation that the reservation made it is lost? Extend the design 5. What should the endhost do if the reservation is declined. Extend the design... 6. What happens if the underlying route changes? Extend the design...

It's hard. Dependencies on consistency. But the states are highly dynamic but agree with each other.

Recap: Circuit vs. Packet Switching¶

Pros for circuit switching:

• Better applicaiton performance (reserved bandwidth)

• More predictable and understandable (w/o failures)

Pros for packet switching:

• Better efficiency

• Faster startup to first packet delivered

• Easier recovery from failure

• Simpler implementation (avoids dynamic per-flow state management in switches)

What does the Internet Use Today?¶

Packet swtiching is the default --> the public Internet

• Limited use of RSVP (Resource Reservation Protocol) within one domain

But you can also buy a dedicated circuit (e.g., MPLS circuits, leased lines, etc.) often used by enterprises from one branch location to another (or to/from cloud)

• Very expensive (e.g., 10-20x higher than a normal connection)

• Often statically set up (manually), long-lived (e.g., years) and per user (vs. per flow)

• So, a far cry from the vision of dynamic reservations that we just discussed

Circuit vs. Packet Switching: A Bit of History¶

The early Internet (70s-80s) packet switched. Well suited to bursty file transfer applications.

The next iteration (80s-90s): research and industry believed we would need circuit switching

• Envisioned that voice/live TV/ would be the Internet's true killer app

• Spent 10+ years trying to realize this vision (man Berkeley folks were pioneers in this space!)

Ultimately a failed vision. Why? All the reasons we discussed... but also

• The killer app became the email and the Web

• People rewrote apps to be adaptive (turns out we didn't really need guaranteed BW)

This is a lesson in how technology can transform user behavior!

More About Packet Switching¶

Recall, packets in flight: pipe view.