Brief History of the Internet(1) - Information Sciences Institutebraden/myfiles/umass.talk.pdf · 2014-04-22 · Internet protocols, but formal discussion of the Internet architecture

Masy 2003 Bob Braden -- New Arch 1

Rethinking the Internet Architecture

Bob Braden

USC Information Sciences Institute

Marina del Rey, CA

Univ of Mass. May 15, 2003


What is “Network Architecture” ?

• A set of fundamental design principles, which can

guide detailed [protocol] engineering.

Architecture: both

a science and

an art.


Network Architecture

• Informal architectural ideas guided the design of the Internet protocols, but formal discussion of the Internet architecture only came 10 years later...

– “The Design Philosophy of the DARPA Internet Protocols”,

David D. Clark, SIGCOMM ‘88, p.106.

• The boundaries of “architecture” are fuzzy: – Bounded from “above” by requirements

– Bounded from “below” by engineering.


Network Architecture

• The “Network architecture” metaphor emerged from

mathematical sciences (CS), not engineering.

– Simplicity is vital, and elegance is desirable

• Founded upon Computer-Sciency kinds of concepts...

– Modularity

– Naming -- global vs. local

– [Communication] state -- Where & how?

– Indirection

– Resource allocation

– Security boundaries -- Where and how?

– Etc...


The End-to-End Principle:

Foundation of the Internet architecture

Rubric: “Dumb network, smart end systems” (Exact opposite of telephone network!)

• Dumb network: – Provides only least common service

• Datagram service: no connection state in routers

• Best effort: all packets treated equally.

– Can lose, duplicate, reorder packets.

• Smart hosts:

– Maintain state to enhance network service (e.g., reliability, ordering...)

– “Fate-sharing”: If a host crashes and loses comm state, applications that are communicating share this fate.


Philosophical Gap

• Deep philosphical gap:

– Telecommunications Engineers: • The Internet is under-engineered -- it does not solve all problems in

the most optimal and controllable manner.

• We like certainty and complexity.

– Internet Designers: • Optimal is NOT the point. The future adaptability of the Internet to

new technologies and new services requires that we NOT over-engineer the Internet!

• We like elegance and simplicity, and we can tolerate uncertainty. Live with it!


So, Where are We?

• The Internet design has been very successful

– Scaled into a huge worldwide infrastructure

– Adapted to many new comm technologies

• Frame Relay, ATM, wireless, optical, ...

– Easily adapted to unforeseen applications -- Web, P2P

– Adapts over a huge dynamic range -- O(106)

• BUT...

– Serious new challenges -- new requirements and issues

– Loss of technical coherence


New Challenges to Architecture

• Commercial Internet

– Business models -- ISPs need to be able to make money

– Need to harness competition to drive innovation

– Legal, political, and public policy issues

• Erosion of trust (Loss of innocence)

– Spam/viruses/worms/DDoS attacks/...

• New technologies and applications

– Optical networking

– IP telephony


Loss of Technical Coherence

• Equipment vendors want to sell boxes

– They are busily designing point solutions to specific

problems; often in conflict, lacking in generality.

– Looks like a downward spiral into technical chaos.


Internet Architectural Principles

P1. Multiplexing

P2. Transparency

P3. Universal connectivity

P4. End-to-End argument

P5. Subnet heterogeneity

P6. Common Bearer Service

P7. Forwarding context

P8. Global addressing

P9. Routing

P10. Regions

P11. Protocol Layering

P12. Minimal Dependency

P13. Security

P14. Congestion

P15. Resource Allocation

P16. Mobility


Ooops...

Every one of these 16 architectural principle categories is problematic in some manner!

(a) Being broken for commercial reasons

(b) Being broken to obtain additional functionality

(c) Protected against unwise optimization only by constant struggle in the IETF.

(d) Represent real unmet requirements

(e) Mods suggested by researchers.

(f) Mods urged by mysterious government agencies

• Details? Need another 2 hours!


NewArch -- the Dream

• Could a new Internet architecture restore some

technical coherence and meet new requirements?

– A small DARPA-funded project, NewArch, has been

trying to answer this question.

• Objective: to figure out what the Internet

architecture would have been if we had known in

1979 what we know today.

• Ignore compatibility/transition issues.


• NewArch Players: – Dave Clark, John Wroclawski, Karen Sollins, & a cast of GRAs at

MIT.

– Bob Braden, Ted Faber, Aaron Falk, & Venkata Pingali at ISI.

– Mark Handley & Scott Shenker at ICIR.

– Noel Chiappa (retired)


NewArch -- the Process

• Re-examine the requirements and assumptions


Original Internet Requirements (1)

• Survivability (robustness)

– Messages must get through, “no matter what”.

• Service generality

– Support widest possible set of applications and service

models, from FTP to Telnet to packet video and voice.

• Diverse network [“sub-net”] technologies

– Heterogeneity is fundamental: must communicate

across arbitrary interconnection of links -LANs,

WANs, wireless, satellite, ...


R

R

R

Host

Hosts

Host

subnet

subnet

subnet

packet

INTERNET

Router [gateway]



Internet Architecture:

Deep Assumptions

• Packet switching

– Unit of data is a packet

– Packets are statistically multiplexed (not TDM)

• Strict protocol layering

– Successive layers of functional abstraction

– Header encapsulation • Headers added/removed in strict LOFO order -- “Stack”model.

• Hop-by-hop forwarding – More robust than source-routed or connection-oriented subnetworks.


Erosion of the End-to-End Principle

A current architectural battleground…

• “Middle boxes” process user packets inside the network.

– E.g., web caches and proxies, application-level firewalls, NAT

boxes, performance-enhancing proxies, …

– They perform useful functions but violate the E2E Principle.

– That is more than religion -- they reduce robustness, generality, extensibility, and simplicity.


Link layer

(subnet-specific)

Internet layer

IP

Transport layer TCP, UDP, SCTP...

Application layer SMTP, HTTP, ...

Marbling the Internet Layer Cake

Physical layer

5

3

2

1

4

4.5 TLS

3.5 IPsec

2.5 MPLS


NewArch -- the Process

• Re-examine the requirements and assumptions

• Try to understand implications for the Internet

architecture of economic, political, and social

forces.

• Examine a set of propositions of the form: • What if we relaxed assumption X?

• What if we added assumption Y?

and pursue a few of the promising Xs and Ys.


Sample of Propositions Considered

• Relaxed assumption X: • X= All packets (e.g., no bit streams)

• X= Protocol layering

• X= Network locator == end-point identifier

• Added assumption Y: • Y= Provide regions of trust

• Y= Support ubiquitous mobility

• Y= Carry congestion state in packet headers

• Y= Empower users to choose ISPs (=> competition)


NewArch -- the Results

• A lot of talk...

– 18 3-hour teleconferences, 3 face-face meetings

– 28 internal working papers

• A few conference papers

• Perhaps some new research directions

• Quite a lot of overlap with earlier work, but within

a more comprehensive framework.

• Too many ideas, too little time... !


Project Publications

• Clark, D., Wroclawski, J., Sollins, K., Braden, R., "Tussle in Cyberspace: Defining Tomorrow's Internet". ACM SIGCOMM 2002.

• Katabi, D., Handley, M., Rohrs, C., "Congestion Control for High Bandwidth-Delay Product Networks", ACM SIGCOMM 2002.

• David Clark, Aaron Falk, Venkata Pingali, and Robert Braden, "FARA: Reorganizing the Addressing Architecture". March 2003.

• Karen Sollins, "Recursively invoking Linnaeus: A Taxonomy of Distributed Naming Systems". February 2003.

• Xiaowei Yang, "NIRA: A New Internet Routing Architecture". January 2003.

• Braden, R., Faber, T., Handley, M., "From Protocol Stack to Protocol Heap -- Role-Based Architecture". HotNets-I, Princeton, NJ, October 2002.


From Protocol Stack to Protocol Heap

-- Role-Based Architecture (RBA)

Bob Braden, Ted Faber USC Information Sciences Institute

Mark Handley

ICSI Center for Internet Research

ACM HotNets I

Princeton University

October 28, 2002


Outline

• Motivation

• Overview of Role-Based Architecture (RBA)

• Using RBA

• Related Work

• Conclusions


Motivation

• The IETF has become an architectural pretzel factory.

– Layer violations

– Sub-layer proliferation

• E.g., MPLS at 2.5, IPsec at 3.5, and TLS at 4.5.

– Feature interactions

• Cross-product complexity

– Erosion of E2E model -- middleboxes

• Firewalls, NATs, proxies, caches, ...

• A paradise for lovers of complexity

• Can we somehow reduce the complexity and increase the

architectural flexibility?


Motivation ...

• Suggestion 1: Replace the traditional protocol layering paradigm with a more general model.

• Many of these problems seem to be related to traditional layering.

• Suggestion 2: Provide a protocol mechanism to attach additional metadata to data packets -- “in-band signaling” -- for middleboxes.

• Attach color-coded “stickies” to packets in the network.

• These suggestions led to the concepts of Role-Based Architecture (RBA)

• Giving up layering has profound consequences for how we think about protocols.


What Does Non-Layered Mean?

• Traditional layered architecture

– Modularity

• Functional unit for each protocol layer.

– Packet header format:

• Sub-header for each layer, forming a logical stack.

– Header processing rules:

• Order: Headers processed in order by layer (LOFO)

• Access: A functional module can read/write only its own sub-

header


• Non-Layered architecture

– Modularity:

• Role: Functional spec of a communication building block.

– Packet header format:

• An arbitrary collection of sub-headers: “role data”.

• These are Role-Specific Headers (RSHs).

• RSHs are addressed to roles.

• Header data structure is now a logical heap of RSHs.

– Processing rules: need new rules for order, access.


RSH Processing in a Node

Role

A Role

B

Role

C

Network Node

Payload RSH

1

RSH

2 RSH 3

Heap

Packet


Objectives of RBA (1)

• Clarity:

– Replace “layer violations” with architected role interactions

• Flexibility

– Roles have more flexible relationships than layers

• Extensibility

– Roles are modular and hopefully orthogonal. No layer restrictions.

• Inband Signaling

– RSHs can act as “stickies”, e.g., to control middle boxes.

• Auditability

– Can leave RSHs after they have been “consumed”, to signal to downstream nodes that a function has been performed.


Objectives of RBA (2)

• Portability

– Allow roles to be sited arbitrarily on nodes.

• For extra credit: mobile roles that migrate among nodes

• Re-Modularization

– Current monolithic protocol layers are large and complex; can re-modularize into smaller units.

• This is not a new idea

• It is unclear how far one should go towards micro-roles

• But RBA gives us freedom of choice on functional granularity

• Security

– Hide particular role data (Don’t muck with my meta-data!)

– RSH might be unit for encryption of role data


Brief Overview of RBA

• Outline

– Role Data

– Role Definition

– Naming and Addressing

– Processing Rules

– Trivial Example

– Implementation: Packet Layout


More About Role Data

• RSHs can be added, modified, or deleted as a

packet is forwarded.

• RSHs subdivide the header information (meta-

data) along role boundaries.

• Granularity of RSHs is an important design parameter

• Trade off processing overhead against reusability

• RSHs generally carry metadata, but some may not,

only modifying processing by their presence.


Defining Roles

• Roles communicate with each other only via RSHs

– (for role mobility)

• Roles may have local APIs to node software.

• A fully-specified role will be specified by:

– Its internal state, its algorithms, its APIs, and the RSHs it will send

and receive.

• Generic roles

– Want to be able to derive a full role specification from a generic

functional definition by stepwise refinement.

– Aid reasoning about protocols and for developing new roles.


More about Roles

• A role instantiation called an actor. • (MJH doesn’t like the Hollywoodiness of this term)

• Roles are often coupled in conjugate pairs

– E.g., {Encrypt, Decrypt} {Compress, Expand}

{Fragment, Reassemble}

• (Undecided: Is a conjugate pair one distributed role with two

actors, or two interrelated roles?)


Naming and Addressing in RBA

• Role type is identified by unique name: RoleID

• “Color-coded”

• RSHs are addressed to role(s)

– Assume an address space for nodes {NodeID} [~IP addr]

– <RoleAddr> ::= <RoleID> @ <NodeID> | <RoleID> @ *

Wildcard NodeID: RSH will be processed by any instance of

the RoleID that it encounters along the path.

• Symbolically, an RSH is:

RSH( <RoleAddr>, ... ; <RSHbody> )

(More accurately: RSH( <RoleAddr>:<access bits>, ... ) )


Processing Rules

• A Role R on node X may access an RSH if:

(1) The RSH is explicitly addressed to R

RoleAddr = R@X or R@*,

(2) or R is promiscously listening for RoleID R’ that is addressed by RSH

Either may be restricted by access control bits.

• Enforce Sequencing rules

– Legal ordering of conjugate roles

• compress -> expand, or encrypt -> decrypt

– Proper nesting: compress -> encrypt -> decrypt -> expand

– Use presence/absence of RSHs (between nodes) plus precedence

rules for roles (within the same node).


Simple Example Using RBA

{ RSH( HBHforward@* ; dest-NodeID, src-NodeID ), /* -> Forwarding role instance in every router */

RSH( Deliver@dest-NodeID ; serviceID, src-processID, payload ), /* Deliver payload to specific service at dest node */

RSH( Reassemble@dest-NodeID ; offset, MFflag},

RSH( TrustScope@* ; <local scope> )

}


Possble RBA Packet Layout

NodeID or zero

RoleID

Flags Stack

Chain Byte Offset

Access

Bits

Element of Index Vector

Index

Vector Heap Area

Payload

Length (bytes) Flags DDescr

RSH Body

RSH

RSH format

...


Using RBA -- Possibilities

• Pure RBA architecture

• All functions, from current link layer to applications, using roles.

• RBA only above the Link Layer

• Probably want to treat the link layer as god-given.

• RBA only above IP layer

• Retain forwarding efficiency of IP in routers.

• RBA overhead then only in end systems and middleboxes

• RBA only in app layer

• We need an application layer architecture; RBA could be a nifty

framework for it. Would still help immensely with middleboxes.

• RBA only as abstraction for reasoning about protocols.


Related Work

• Hasn’t this all been done before? Not really...

• Modular construction of protocol stacks

– Peterson et. al. 1991 (X-kernel), Tschudin 1991.

• Protocol decomposition into micro-protocols

– For re-usability & customization -- O’Malley & Peterson 1992, Bhatti&Schlichting 1995, Kohler et al 2000 (Click), Kohler et al 1999 (Prolac).

– For performance -- Haas 1991, Zitterbart et al 1993.

• These all focused on protocol implementations, not on the protocols themselves.

• RBA is orthogonal concept; in fact, the earlier work may provide a basis for realizing RBA.


Conclusions ...

• This is a position paper.

– We did not build an RBA prototype.

– We have worked through some simple examples.

– Some of the basic definitions are still subject to debate.

• I hope I have convinced you that a non-layered

approach to protocols might not be totally crazy.

– But we are so used to thinking in a layerist manner that

using RBA does twist the head a bit.


Conclusions

• Advantages of RBA

– Modularizes functionality better then layering does.

– Provides an explicit place for middlebox metadata

– Should create fewer unexpected feature interactions

• Disadvantages of RBA

– Replacement of deployed protocols

– Less efficient (header space, processing).

– Greater flexibility may itself increase complexity and

confusion.


• http://www.isi.edu/newarch/

Documents

Brief History of the Internet(1) - Information Sciences Institutebraden/myfiles/umass.talk.pdf · 2014-04-22 · Internet protocols, but formal discussion of the Internet architecture