Part 2: Internet Design Principle

Goals: identify, study principles that can guide network architecture bigger issues than specific protocols or implementation wisdom, synthesis: the really big picture

Overview: Internet design principles rethinking the Internet design principles packet-switching versus circuit-switching revisited

Part 2

Key questions
How to decompose the complex system

functionality into protocol layers? Which functions placed where in network, at which layers? Can a function be placed at multiple levels ?
Answer these questions in context of Internet

Part 2

Common View of the Telco Network

brain (smart) brick (dumb) lock (you cant get in)

Part 2 3

Common View of the IP Network

Part 2

Internet E2E Argument

functions placed at the lower levels may be

redundant or of little value when compared to the cost

of providing them at the higher level

sometimes an

provided by the communication system (lower levels) may be useful as a performance enhancement the telephone world of dumb end-systems (the telephone) and intelligent networks.

incomplete version of the function

This leads to a philosophy diametrically opposite to

Part 2

Example: Reliable File Transfer

Host A Appl. OK OS
checksum

Host B Appl. OS

Solution 1: make each step reliable, and

then concatenate them

Solution 2: each step unreliable: end-to-

end check and retry

Part 2

Discussion
Is solution 1 good enough? No - what happens if components fail or misbehave (bugs)? Is reliable communication sufficient: No - what happens if disk errors? so need application to make final correctness check Thus, full functionality can be entirely implemented

at application layer; no need for reliability from lower layers

Part 2

Discussion
Q: Is there any reason to implement reliability at lower layers? A: YES: easier (and more efficient) to check and recover from errors at each intermediate hop e.g: faster response to errors, localized retransmissions

Part 2

Tradeoffs
application has more information about the data

and semantics of required service (e.g., can check only at the end of each data unit) constraints in data transmission (e.g., packet size, error rate)

lower layer has more information about

Note: these trade-offs are a direct result of

layering!

Part 2

End-to-end Argument: Examples

Error control and reliable transmission Audio conferencing Digital music player Q: should lower layer try to achieve as low error rate as possible? Secure transmission of data Per-hop vs. end-to-end encryption Data integrity, privacy, and authentication Q: should network automatically encrypt all traffic?
Part 2 10

End-to-end Argument: More Examples

RISC architectures

Extensible operating systems

Part 2

11

Internet & E2E Argument

network layer provides one simple service: best

effort datagram (packet) delivery

transport layer at network edge (TCP) provides

end-end error control performance enhancement used by many applications (which could provide their own error control) all application layer functionality network services: DNS implemented at application level

all other functionality

Part 2

12

Internet & E2E Argument

Discussion: congestion control, flow control: why at transport, rather than application layer? congestion control needed for many application (assumes reliable application-to-tcp data passing) many applications dont care about congestion control its the networks concern consistency across applications- you *have* to use it if you use TCP (social contract) why do it at the application level

Flow control application knows how/when it wants to consume data Congestion control application can do tcp-friendly cc

Part 2

13

Internet & E2E Argument

Why not at the link/network layer
1: not every application needs/want it 2: lots of state at each router (each connection

needs to buffer, need back pressure) its hard

Part 2

14

E2E Argument: Interpretations

One interpretation: A function can only be completely and correctly implemented with the knowledge and help of the applications standing at the communication endpoints
Another: (more precise) a system (or subsystem level) should consider only functions that can be completely and correctly implemented within it.

Alternative interpretation: (also correct ) Think twice before implementing a functionality at a lower layer that you believe is useful to an application If the application can implement a functionality correctly, implement it a lower layer only as a performance enhancement
Part 2 15

End-to-End Argument: Critical Issues

end-to-end principle emphasizes:

function placement correctness, completeness overall system costs

Philosophy: if application can do it, dont do it at a

lower layer application best knows what it needs add functionality in lower layers iff (1) used by and improves performances of many applications, (2) does not hurt other applications

allows

cost-performance tradeoff
Part 2 16

End-to-End Argument: Discussion

end-end argument emphasizes correctness &

completeness, does not emphasize:

complexity: is complexity at edges result in a simpler

architecture? evolvability: ease of introduction of new functionality: ability to evolve because easier/cheaper to add new edge applications than change routers? technology penetration: simple network layer makes it easier for IP to spread everywhere

Part 2

17

Internet Design Philosophy (Clark88)

In order of importance:
0

Connect existing networks

1.

Survivability

initially ARPANET, ARPA packet radio, packet satellite network ensure communication service even with network and router failures

2. Support multiple types of services

3. Must accommodate a variety of networks 4. Allow distributed management 5. Allow host attachment with a low level of effort 6. Be cost effective
7.

Allow resource accountability

Part 2 18

1. Survivability

Continue to operate even in the presence of

network failures (e.g., link and router failures)

Decision: maintain e2e transport state only at

as long as network is not partitioned, two endpoints should be able to communicate any other failure (excepting network partition) should be transparent to endpoints

end-points

a.k.a. fate-sharing

Internet: stateless network-layer architecture No notion of a session/call at network layer Grade: __ A-: routing algorithm fail-over path is non-optimal, non-traffic sensitive. (Note: ISPs worry about this)

eliminate the problem of handling state inconsistency and performing state restoration when router fails

it is acceptable to lose the state information associated with an entity if at the same time the entity itself is lost

Part 2

19

2. Types of Services
add UDP to TCP to better support other apps e.g., real-time applications arguably main reason for separating TCP, IP datagram abstraction: lower common

denominator on which other services can be built

Grade: __ __

service differentiation was considered (remember ToS?), but this has never happened on the large scale (Why?)

Part 2

20

3. Variety of Networks
Very successful (why?) because the minimalist service; it requires from underlying network only to deliver a packet with a reasonable probability of success does not require: reliability in-order delivery The mantra: IP over everything Then: ARPANET, X.25, DARPA satellite network.. Now: ATM, SONET, WDM Grade: __ __
Part 2 21

Other Goals

Allow distributed management Administrative autonomy: IP interconnects networks

Grade: __
__

each network can be managed by a different organization different organizations need to interact only at the boundaries but this model complicates routing

Cost effective sources of inefficiency

header overhead retransmissions routing

but optimal performance never been top priority Grade: __

__
Part 2 22

Other Goals (Contd)

Low cost of attaching a new host
not

a strong point higher than other architecture because the intelligence is in hosts (e.g., telephone vs. computer) bad implementations or malicious users can produce considerably harm (remember fatesharing?) Grade: __
__

Accountability Grade: __
Part 2 23

Summary: Internet Architecture

packet-switched

datagram network IP is the glue (network layer overlay) IP hourglass architecture

TCP

UDP

IP Satellite Ethernet ATM

stateless architecture no per flow state inside network

all hosts and routers run IP

IP hourglass

Part 2

24

Summary: Minimalist Approach

Dumb network IP provide minimal functionalities to support connectivity addressing, forwarding, routing

Smart end system transport layer or application performs more sophisticated functionalities flow control, error control, congestion control

Advantages accommodate heterogeneous technologies (Ethernet, modem, satellite, wireless) support diverse applications (telnet, ftp, Web, X windows) decentralized network administration

Part 2

25

But that was yesterday . what about tomorrow?

Part 2

26

Rethinking Internet Design

Whats changed?

operation in untrustworthy world

endpoints can be malicious If endpoint not trustworthy, but want trustworthy network more mechanism in network core more demanding applications end-to-end best effort service not enough new service models in network (Intserv, diffserv) new application-level service architecture built on top of network core (e.g., CDN, p2p) multiway communication (e.g., teleconferencing, audio/video broadcasting, multiplayer game)
Part 2 27

Rethinking Internet Design

Whats changed?

ISP service differentiation

ISP doing more (than other ISPs) in core is competitive advantage Rise of third party involvement interposed between endpoints (even against will) e.g., US recording industry less sophisticated users e.g., thin clients (PDAs, set-top boxes, cell-phones) users lack expertise

Historical example: Kerberos 5 pulls inside the programming interface for the function of replay prevention
28

All five changes motivate shift away from end-end! Part 2

Whats at stake?
At issue is the conventional understanding of the
`Internet philosophy freedom of action user empowerment end-user responsibility for actions taken lack of control in the net that limit or regulate what users can do The end-to-end argument fostered that philosophy because it enables the freedom to innovate, install new software at will, and run applications of the users choice
[Blumenthal and Clark, 2001]
Part 2 29

Technical response to changes

Trust: emerging distinction between what is in network (us,

trusted) and what is on (i.e. attached to) the network (them, untrusted). E2e argument services in the network is undesirable E2e argument also guides the placement of services on the network

Modify endpoints

Harden endpoints against attack Endpoints/routers do content filtering: Net-nanny CDN, ASPs: rise of structured, distributed applications in response to inability to send content (e.g., multimedia, high bw) at high quality

Part 2

30

Technical response to changes

Add functions to the network core:

filtering firewalls application-level firewalls NAT boxes active networking All operate within network, making use of application-level information which addresses can do what at application level? If addresses have meaning to applications, NAT must understand that meaning

E.g. arguments for FTP PORT command include an IP address in ASCII! NAT needs to adjust TCP sequence number!

Need a really compelling case!

E.g. multicast never really made it for 20 years

Part 2 31

Firewalls
firewall isolates organizations internal net from larger Internet, allowing some packets to pass, blocking others.

administered network firewall

public Internet

Part 2

32

Firewalls: Why
prevent denial of service attacks: SYN flooding: attacker establishes many bogus TCP connections, no resources left for real connections. prevent illegal modification/access of internal data. e.g., attacker replaces CIAs homepage with something else allow only authorized access to inside network (set of authenticated users/hosts) two types of firewalls: packet-filtering application-level
Part 2 33

Packet Filtering

Should arriving packet be allowed in? Departing packet let out?

internal network connected to Internet via router firewall

router filters packet-by-packet, decision to forward/drop

packet based on:

source IP address, destination IP address TCP/UDP source and destination port numbers ICMP message type TCP SYN and ACK bits
Part 2 34

Packet Filtering
Example 1: block incoming and outgoing datagrams with IP

protocol field = 17 and with either source or dest port = 23. all incoming and outgoing UDP flows and telnet connections are blocked.

Example 2: Block inbound TCP segments with ACK=0.

prevents external clients from making TCP connections with internal clients, but allows internal clients to connect to outside.

Part 2

35

Application gateways
Filters packets on
host-to-gateway telnet session
application gateway

gateway-to-remote host telnet session

application data as well as on IP/TCP/UDP fields. Example: allow selected internal users to telnet outside.

router and filter

1. Require all telnet users to telnet through gateway. 2. For authorized users, gateway sets up telnet connection to dest host. Gateway relays data between 2 connections 3. Router filter blocks all telnet connections not originating from gateway.

Part 2

36

NAT: Network Address Translation

Motivation: local network uses just one IP address as far as outside

world is concerned: no need to be allocated range of addresses from ISP: just one IP address is used for all devices can change addresses of devices in local network without notifying outside world can change ISP without changing addresses of devices in local network devices inside local net not explicitly addressable, visible by outside world (a security plus).

Part 2

37

NAT: Network Address Translation

Implementation: NAT router must:

outgoing datagrams: replace (source IP address, port #) of

every outgoing datagram to (NAT IP address, new port #) . . . remote clients/servers will respond using (NAT IP address, new port #) as destination addr.

remember (in NAT translation table) every (source IP address,

port #) to (NAT IP address, new port #) translation pair

incoming datagrams: replace (NAT IP address, new port #) in

dest fields of every incoming datagram with corresponding (source IP address, port #) stored in NAT table

fix TCP sequence number if necessary (e.g. for FTP PORT

command PORT a1,a2,a3,a4,b1,b2)

Part 2

38

NAT: Network Address Translation

2: NAT router changes datagram source addr from 10.0.0.1, 3345 to 138.76.29.7, 5001, updates table NAT translation table WAN side addr LAN side addr

138.76.29.7, 5001 10.0.0.1, 3345

1: host 10.0.0.1 sends datagram to 128.119.40, 80

S: 10.0.0.1, 3345 D: 128.119.40.186, 80

S: 138.76.29.7, 5001 D: 128.119.40.186, 80

1
10.0.0.4
S: 128.119.40.186, 80 D: 10.0.0.1, 3345

10.0.0.1
10.0.0.2

138.76.29.7

3: Reply arrives dest. address: 138.76.29.7, 5001

S: 128.119.40.186, 80 D: 138.76.29.7, 5001

10.0.0.3 4: NAT router changes datagram dest addr from 138.76.29.7, 5001 to 10.0.0.1, 3345
Part 2 39

NAT: Network Address Translation

16-bit port-number field:
60,000

simultaneous connections with a single LAN-side address!

NAT is controversial:

routers should only process up to layer 3 violates end-to-end argument

NAT possibility must be taken into account by app designers, eg, P2P applications
address

IPv6

shortage should instead be solved by

Part 2

40

Traversal of UDP through NATs

Q: Suppose H1, H2 are behind NAT box N1 and N2, respectively, how do H1 and H2 talk to each other? A: Using STUN (Simple Traversal of UDP through NATs) to learn the NAT type and addr mapping
1. 2. 3. 4. 5.

Port prediction

H1 send request to a public STUN server S1; S1 replies with current mapping at N1: (GA1,GP1) Similarly H2 learns current mapping at N2: (GA2,GP2) H1 and H2 predict ports GP1 and GP2 and exchange mapping through out-of-band communication H1 sends a packet to (GA2,GP2) (which is dropped by N2 but causes N1 to initiate state) H2 sends a packet to (GA1,GP1) (causing N2 to initiate state) port-preserving NAT: dp = 0; symmetric NAT: dp = 1, 2 (there is a window of vulnerability)

Part 2

41

Traversal of TCP through NATs

Q: Suppose H1, H2 are behind NAT box N1 and N2, respectively, how do H1 and H2 talk to each other? A: port prediction is similar, but how about seq#?

STUNT #1: (STUNT = STUN and TCP too)

STUNT #2

H1 and H2 send SYN with small TTL to set up state at N1/N2; communicate this info to STUNT server, which then spoof a SYNACK to both ends Only H1 sends SYN with small TTL. After that H1 reset connection and opens passive TCP socket on same port H2 then sends a SYN to (GA1,GP1) H1 and H2 exchange mapping and sequence number out of band, each sends a SYNACK to the other side

NATBlaster

If you are interested, read IMC05 paper:

Characterization and Measurement of TCP Traversal through NATs and Firewalls

Part 2

42

What is an Active Network ?

Depends on who you ask! active services: application-level services exploiting position

within the network to provide enhanced service CDN streaming media caches

capsule approach: packets carry programs, active node

executes program when code-carrying packet arrives to active node

code may determine what to do with packet may implement other service: e.g., network management, reliable multicast

Part 2

43

The capsule approach to active networks

Network architecture that allows :

application-customized code to be dynamically deployed in the network

customized-code to be executed in controlled framework within network

Similar to extensible operating systems (SPIN, Synthesize etc)

the new equation:

Packet = Code + data sort of like postscript
Part 2 44

Capsules
ANTS Header IP header
Type

Version

Type

Previous Address

Dep fields Payload

Identifier for the forwarding routine to be executed (carries code by reference) Where to get the forwarding routine from if it is not available in the present node (Code Distribution)

Previous address

Dependent Fields

Parameters for the forwarding code Payload

Header + data of higher layers

Part 2

45

Active networking and End-to-End Arguments

End-to-end principle: lower layers should have

minimum functionality, but support widest variety of applications possible active networking: support all higher-level applications minimum common functionality: ability to execute code: programmable versus preprogrammed low layer functionality

Part 2

46

Active networking: transparency?

Transparency: use of network by others not very

visible (can more or less predict behavior of network)

Active networking: transparency difficult need to constrain interactions among programmable entities in router (who knows what they will try to do) like OS trying to constrain interaction among processes!

Part 2

47

KISS
success of LAN protocols, RISC architecture: KISS! building complex functions into network optimizes

network for small number of services, while substantially increasing cost for uses unknown at design time

end-to-end argument does not oppose active

networks per se but instead strongly suggests that enthusiasm for the benefits of optimizing current application needs by making the network more complex may be misplaced
Part 2 48

Epilogue: will IP take over the world?

Reasons for success of IP:
reachability:

reach every host, adapts topology when links fail. heterogeneity: single service abstraction (best effort) regardless of physical link topology

Note: our grading for these: A-, A

Part 2

49

Epilogue: will IP take over the world?

There are many other claimed (or commonly accepted) reasons for IPs success
IP already dominates global communications IP is more efficient IP is more robust IP is simpler IP supports real-time apps and telephony

Are these really true?

lets take a closer look

Part 2 50

1. IP already dominates global communications?

business revenues: ISPs: 13B

Broadcast TV: 29B Cable TV: 29.8B Radio broadcast: 10.6B Phone industry: 268B

59% US households

Q: IP equipment cheaper? Economies of scale? (lots of routers?) Q: per-device, IP is cheaper (one line into house, multiple devices) Q: # bits carried in each network? Q: Internet, more traffic and congestion is spread among all users (bad?)

Router/telco switch markets: Core router: 1.7B; edge routers: 2.4B SONET/SDH/WDM: 28B, Telecom MSS: 4.5B

Part 2

51

2. IP is more efficient?
Statistical multiplexing versus circuit switching Link utilization: Avg. link utilization in Internet core: 3% to 30% (ISPs: never run above 50%) Avg. utilization of Ethernet is currently 1% Avg. link utilization of long distance phone lines: 33% low IP link utilization: purposeful! predictability, stability, low delay, resilience to failure Recall: overprovisioning is the markets answer to the challenge of Internet QoS At low utilization, we

multiplexing!

forfeit benefits of statistical

Part 2

52

3. IP is more robust?
Median IP network availability: downtime: 471 min/yr Avg. phone network downtime: 5 min/yr Convergence time with link failures:

(99.9% reliability)

(99.999% reliability)

BGP: 3 15 minutes but ~ 1 sec with intra-domain, e.g., OSPF (with proper timer configurations) SONET: 50 ms Q: why is fast convergence challenging in IP networks?

Inconsistent routing state

- distributed route computation + in-band signaling - More hops backup path computation more sophisticated - In general, circuit switching with few hops is actually easier to recover from failure than IP general net

human misconfigurations in-band signaling (signaling and data share same network) routing computation complex
Part 2 53

4. IP is simpler?
Intelligence at edge, simplicity in core

Cisco IOS: 8M lines of code (Q: how many versions?) Telephone switch: 3M lines of code

Q: where does most of the complexity lie?

Line-card complexity:

Router: 30M gates in ASICs, 1 CPU, 300M packet buffers Switch: 25% of gates, no CPU, no packet buffers

Key: simple abstraction/interface simple implementation

5. Support of real-time apps & telephony over IP

Not yet

Part 2

54

Discussion: benefits of IP?

Part 2

55

Discussion: benefits of IP?

IP supports many different types of data applications at a

wide range of data rates

phone network: 1 of many services (voice, fax, touch-tone service, 800 numbers, teletype, hearing impaired services, lots of enhanced voice services, voicemail)

IP traffic, services more diverse (?). IP works at higher

bandwidths

factually true for end applications, but cores are both high speed (in fact core telephone switches are faster why?) Is it really true? implicit: less setup cost, less resources used not that important given utilization figures

Claim: IP supports short bursty connections better

IP has 1 rtt transaction times, phone network is at least 2

rtt (setup plus transaction)

Part 2

56

Big picture: supporting new applications losing the IP hour glass figure?
middle age: a narrowing mind, a widening waist

Applications TCP UDP

Applications IP love handles NAT diffserv IPSEC mobile IP mcast

intserv

TCP UDP

IP
Eth token PPP 802.11
radio, copper, fiber

Eth token PPP 802.11

radio, copper, fiber

IP hourglass

Middle-age IP hourglass ?
Part 2 57

Big picture: supporting new applications losing the IP hour glass figure?
middle age: a expanding mind, a slim waist

Applications TCP UDP

client server apps

application overlays overlay services TCP UDP IP Eth token PPP 802.11

IP
Eth token PPP 802.11
radio, copper, fiber

radio, copper, fiber

IP hourglass
Part 2 58