Architecture is maximizing the invariants and minimizing the discontinuities.
Preface:
What are the seven unanswered questions of network architecture?
These questions were uncovered about 1975 as the ARPAnet started transitioning to the Internet.
That was 30 years ago. Why are these questions still unanswered?
What are the consequences?
How could we start answering them?
Chapter 1: Foundations for Network Architecture
Getting in a mindset to return to fundamentals
Sometimes we need a concept to make progress, but then once we have we no longer need it.
Like Climbing a ladder, but then realizing we can throw it away.
What are the benefits and pitfalls of formal methods?
What are the levels of abstraction that characterize a good architecture?
Chapter 2: Protocol Elements
Review of the basics of protocols
Separating Mechanism and Policy in a network protocol.
What are the common mechanisms?
Chapter 3: Patterns in Protocols
Clash of Titans: 35 year war between the new networking ideas and the big monopolies:
IBM and Phone companies.
Beads-on-a-string versus layering (the connection-oriented/connectionless debate).
Patterns that result from separating Mechanism and Policy, yielding simpler protocols.
Finding a useful synthesis of connection/connectionless.
Another surprise: connectionless is maximal shared state, not minimal.
Chapter 4: Stalking the Upper Layer Architecture
What happened when we tried to figure out what was above Transport?
The ARPANet used Operating Systems as a guide and to great advanatage.
OSI made some progress but the on-going conflict made it hard to see.
Turned out there were limits to using Operating Systems as a model for applications.
A User perspective yields a richer Application Architecture.
Chapter 5: Naming and Addressing
Dr Seuss has sage advice for the hardest, most subtle, most important problem in networking.
Work on naming in logic and mathematics does not help,
But work on operating systems provides the basis:
MIT Professor J. Saltzer's 1982 paper.
A generalization of Saltzer's ideas leads to a more complete result, and answers.
What do we need to name? What needs an address?
The Internet has only half the required architecture for naming and addressing!
IPv6 fails to measure up. Less than too little too late.
But she didn't do it, and now it is too late. (For the IETF.)
Chapter 6: Divining Layers
Our previous experience has not been satisfactory.
Layers seem even more inherent to networking than to operating systems.
What were we missing?
What does the problem tell us?
Networking is Inter-Process Communication (IPC)
And only IPC
Not separate hand-crafted layers, but one layer that repeats: a true commodity.
We were right to split TCP and IP, but we were wrong to put them in different layers.
The Network Layer was the last vestige of beads-on-a-string that needed to be eradicated.
Addresses are not what we thought. They are identifiers internal to IPC.
No need for an application to ever see an address.
Chapter 7: The Network IPC Model
Only two protocols required: one for data transfer, one for management,
and a couple of optional headers.
Problems with layers are resolved. They no longer get in the way, quite the opposite.
Resulting structure is: more regular, easier to manage, less costly to operate.
A full Addressing architecture is an inherent part of the repeating DIFs.
It is impossible to get addressing wrong, while the IETF continues to find new ways to get it wrong.
Inherently more secure network.
The DIF describes not only network layers but IPC aspects of traditional applications
Examples: Relaying part of email, Two-phase commit in online transaction processing, Peer-to peer.
Chapter 8: Making Addresses Topological
Network address is supposed to be location-dependent. What does that mean?
Cannot tie an address to graph of the network. Want location-dependence, not route-dependence.
How would we construct the topology of a network?
Can we abstract useful concepts of distance and direction, and apply them to a hierarchy of subnets?
Addressing implications of a single repeating layer:
No need for a single, global address space.
Private address spaces are the norm, not a special case.
NATs are either everywhere or nowhere depending on your perspective.
The Internet is essentially an e-mall in a seedy part of town. Why not upscale e-malls in a safe part of town?
Instead of every PC joining the network, networks join other networks.
Resulting new network is a much richer, more competitive environment for everyone, spurring innovation.
Chapter 9: Multihoming, Multicast, and Mobility
Why are these so hard?
If you have complete addressing, multihoming is built-in, no additional mechanism is required.
In a repeating architecture, Multicast devolves into unicast.
Mobility is dynamic multihoming.
With a full addressing architecture, manipulating IPC for multi-party, moving applications, etc. are inherent.
A new protocol is not required for each application that needs something, i.e. No need for SIP.
Chapter 10: Backing Out of a Blind Alley
The Internet is an unfinished demo living on Moore?s Law and 30 years of band-aids.
The success of the Internet was due more to the action of politicians than engineers and scientists.
What about the end-to-end principle?
How socio-economic pressures lead to a bunker mentality, groupthink, and ultimately stagnation.
How research emulating venture capitalists contributed to the stagnation.
How our universities failed to distill principle, to keep us honest, and teach what engineers needed to know.
What can be done to get networking back on track?
Review of the properties of the IPC model and implications for the future.