Advanced Internet Technologies

PD Dr. Dennis Pfisterer

Institut für Telematik, Universität zu Lübeck

http://www.itm.uni-luebeck.de/people/pfisterer

Fundamental Internet Design Principles

#1

“There’s a freedom about the Internet: As longas we accept the rules of sending packetsaround, we can send packets containing

2

around, we can send packets containinganything to anywhere.”

[berners-lee99weavingtheweb]

• Network of networks

• A global-scale network

• “An electronic communications network that connects computer networks and organizational computer facilities around the world"

What is the internet/Internet?

networks and organizational computer facilities around the world" (Merriam-Webster Dictionary)

• “A computer network consisting of a worldwide network of computer networks that use the TCP/IP network protocols to facilitate data transmission and exchange" (WordNet, Princeton University)

• “Any set of computer networks that communicate using the Internet Protocol" (Wictionary)

3

Some Historical Facts1974 – First time reference to „internet“ as a shortcut for „internetworking“

– RFC 675, Internet Transmission Control Program, Vint Cerf et al.

1980 – RFC 768 (UDP) for unreliable data transmission of voice packets

� Split into Internet/Transport Layer

1981 – RFC 791 (Internet Protocol), RFC 792 (ICMP),RFC 793 (TCP) adopted for use

� TCP/IP

4

� TCP/IP

1990 – Removed last centralized element of the Internet (EGP)

– Introduction of Border Gateway Protocol (BGP), RFC 1105

1989 – Invention of the WWW (Hypertext Concept) by Tim Berners-Lee at CERN

1992 – US Congress allows commercial activities on the Internet

1993 – First graphical Internet (HTTP-based) browser: Mosaic

1994 – Classless Inter-Domain Routing (CIDR): decrease routing table size, better use

IPv4 address space

Growth of the Internet

1.000.000

10.000.000

100.000.000

1.000.000.000Internet Host Count

5

1

10

100

1.000

10.000

100.000

1975 1980 1985 1990 1995 2000 2005 2010 2015

Hosts

Year

Datasource: http://www.isc.org

Constant Change

350

400

450

500

RFCs per Year

6

0

50

100

150

200

250

300

1965 1970 1975 1980 1985 1990 1995 2000 2005 2010 2015

RFCs

Year

TCP/IP Model: Different Terminology

7Figure source: http://en.wikipedia.org/wiki/TCP/IP_model

TCP/IP Model (this lecture)

Transport

Application

Transport

Application

…00110010101 00110010101 …

8

Link Layer

Internet

Transport

Link Layer

Internet

Transport

Link Layer

Internet

Link Layer

Internet

TCP/IP Model &Typical Usage

Application HTTP, SMTP, IMAP, SSH, DNS, Skype, …

9

Link Layer (L1&L2)

Internet (L3)

Transport (L4) TCP, UDP, GRE, SCTP, …

IP (IPv4, IPv6), ICMP (v4, v6), IGMP, IPSec, …

Ethernet, ATM, FDDI, WiFi, …

(Deployed) Innovations at Different Layers

Application

� HTTP: Web 1.0 (Billions of Web pages), Web 2.0, Blogs,

Social Networks/Bookmarks, Facebook, Twitter, …

� E-Mail: SMTP, POP3, IMAP, LDAP, WebMail

� Other: Web Services, SSH, RSS-feeds, Podcasts,

Videoconferencing, VPNs, Skype, BitTorrent, …

Many, many more…

10

Link Layer

Internet

Transport

� Many, many more…

� ADSL, WiFi, WiMax, GPRS, EDGE, UMTS, ATM, SDH,

Bluetooth, FDDI, Ethernet, Modems, CableModems, and

many more…

� IPv6 (?)

• Average traffic May’10-April’11: 950 Gigabit/s (~120GB/s)

DE-CIX IPv4 Statistics

11Figure source: http://www.de-cix.net/about/statistics/

• Average traffic May’10-April’11: 102 MByte/s– <<1% of IPv4 traffic

DE-CIX IPv6 Statistics

#12Figure source: http://www.de-cix.net/about/statistics/

• IPv4 remains predominant at network level

• Often called “small waist” of the Internet

– Core protocol enabling “internetworking”

The “small waist” of the Internet

“internetworking”

– Goals• maximize number of usable networks

• allow easy adaption by new networks

– Least common denominator for a wide variety of networking technologies

13Figure source: [deering01watchingthewaist]

• Network-agnostic

– Allows interconnecting different

networking technologies to form

larger networks

– Hides networking details and topology

Small Waist: Advantages

– Hides networking details and topology

changes

– Global addressing of devices

• Why a single “small waist” protocol?

– Only a single application interface

– Maximize interoperability

14Figure source: [deering01watchingthewaist]

• The only thing that is constant in the Internet is change, exponential growth and innovation– …and IPv4

• How did IPv4 manage to remain (nearly) unchanged since

Endurance of IPv4

• How did IPv4 manage to remain (nearly) unchanged since the beginning of the Internet?– What are the fundamental design principles boosting its enormous success?

– What are the rules Berners-Lee refers to?

• Is the secret of success an intrinsic property of the Internet’s architecture?

15

Architecture of the InternetArchitecture of the Internet

“Many members of the Internet communitywould argue that there is no architecture, butonly a tradition, which was not written downfor the first 25 years (or at least not by the IAB).

17

However, in very general terms, the communitybelieves that the goal is connectivity, the toolis the Internet Protocol, and the intelligenceis end to end rather than hidden in thenetwork.”

(RFC 1958, 1996)

• Effective interconnection of (existing) networks– At this time: ARPANET & ARPA packet radio network

– Anticipated that more new network types will evolve

• Design Decision: Interconnect existing networks using

Fundamental Design Goals of the Internet

• Design Decision: Interconnect existing networks using gateways and an internetworking protocol– It was felt necessary to incorporate existing and future networks

– These are natural administrative borders (autonomous systems)

• Alternative: All-encompassing novel network system – Including transmission media, protocols, etc.

– Higher degree of integration � higher performance

18

• Design decision: Packet Switching

– Alternative: Circuit switching

– At this time, circuit switching networks were predominant (e.g., POTS, X.25, …)

Fundamental Design Decisions

predominant (e.g., POTS, X.25, …)

• Pros of Packet Switching

– Existing ARPA networks were packet switched

– Applications such as remote login were well supported

– A lot of expertise existed with packet switching

19

Circuit Switching (w/o redundancy)

Connection

State

Connection

State

1.) Setup

ConnectionConnection

State

Connection

State

Connection Connection

2.) Signal

Connection

Connection

State

Connection

State

20

Connection

State

Connection

State

Packet SwitchingConnection

State

Connection

State Connection

State

Connection

State

21

Circuit Switching vs. Packet SwitchingCircuit Switching Packet Switching

3 Phases: Setup, Data Exchange, Termination Only data exchange

Bandwidth guaranteed Bandwidth only allocated when data flows

Bandwidth not reduced by other transmissionsData rate varies over time depending on

cross/other traffic

22

cross/other traffic

Resources are reserved/blocked even if no data is

transferredNo resource reservation

Can provide QoS guarantees regarding latency,

loss, jitter, and order of packet delivery

No QoS guarantees regarding congested links,

jitter, loss, latency or an in-order delivery of packets

Higher cost due to dedicated resources More cost effective, often better performance

Examples: POTS, X.25 (ISDN), HSCSD (GSM) Examples: Ethernet, IP

Examples (packet switched, connection-oriented): Frame Relay, ATM, MPLS

“From these assumptions comes thefundamental structure of the Internet:

a packet switched communications facility inwhich a number of distinguishable networks

23

which a number of distinguishable networksare connected together using packetcommunications processors called gatewayswhich implement a store and forward packetforwarding algorithms.”

[clark88designinternet]

• What is „effective“ interconnection“? (major top-level goal)

• 2nd level goals (in order of importance, [clark88designinternet])

1. Communication must continue despite loss of networks or gateways

2. Supportmultiple types of communications service

Second Level Goals

3. Accommodate a variety of networks

4. Permit distributed management of its resources

5. Be cost effective

6. Permit low-effort host attachment

7. The resources used must be accountable

• Designed for the military and operated in hostile environments

� Survivability is more important than cost or accountability– Today’s Internet architecture still reflects this order of importance

24

• Communication must continue despite loss of networks or routers

– Urban Legend: to survive a nuclear attack

– Includes reconfiguration (adding and removing links and routers), temporary or permanent failure, …

• Should not affect the state of a connection between two entities

Survivability on intermediate failures

• Should not affect the state of a connection between two entities– State of a connection: #packets transmitted/acknowledged, …

– Connections continue unless there is a network partition

– Connection state must not be lost on transient failures

• Approach taken by the Internet

– Fate Sharing (discussed later)

– Alternative: Replication of state to provide safe failovers (complex, security issues, …)

25

• Different (application) requirements require several types

of service

– Speed

– Latency and Jitter

Multiple types of communications service

– Reliability

– In-order delivery

• Example: file transfer vs. voice transport

• Not all networks support different types

– E.g., ISDN data networking has a fixed data transfer rate

26

• IP solution

– Initially, TCP and IP were one protocol

– No application choice for different communication services

– Split up into TCP (reliability over unreliable links) and UDP

Multiple types of communications service

– Split up into TCP (reliability over unreliable links) and UDP

(unreliable datagram service)

• Some networks don’t offer unreliable transport

– A source for delay/jitter are mechanisms providing reliability

(due to retransmissions after timeouts and in-order delivery)

– Only a best-effort service is provided, no guarantees given

27

• Only impose minimal requirements on networks– Must be able to transport packets or datagrams

– Minimal packet size ~100 Byte

– Delivery with good, but not perfect reliability

– Support for addressing (if not point-to-point)

Accommodate a variety of networks

– Support for addressing (if not point-to-point)

• A number of services are explicitly not required– Reliable, in-order delivery

– Broad- and multicast

– Support for multiple service types

– Prioritized delivery

28

• Permit distributed management of its resources– Autonomous systems managed by each authority

– Gateways provide transitions (no need for full trust)

• Be cost effective– ?

Remaining 2nd level goals

– ?

• Permit low-effort host attachment– TCP/IP implementation must exist for the network and host

• The resources used must be accountable– Few tools for accounting

– Mainly traffic-based at peering-points

– Time/Traffic-based accounting for end-users

29

• “The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan” (RFC1958)

– Evolutionary design considered one of the key factors of success

• Current design motivated by a set of requirements/goals imposed

Architectural Principles of the Internet

• Current design motivated by a set of requirements/goals imposed by applications

– As requirements change, the architecture might change as well

• Some fundamental design principles have (incidentally?) emerged

– Robustness principle

– Fate Sharing

– End-to-end principle

– Internet Transparency

30

Fundamental Design PrinciplesFundamental Design Principles

• “Be conservative in what you send, liberal in what you accept”

– Attributed to John Postel (in RFC 761)

• More guideline than principle for implementing Internet Protocols

– Implementers should stick to the standards (i.e., RFCs) but be lenient in

Robustness principle

– Implementers should stick to the standards (i.e., RFCs) but be lenient in

accepting (maybe non-standard or erroneous) data

– Do not expect peers to be well-behaving or error-free

� Handle erroneous data gracefully and do not crash

• Goal: Increased interoperability and robustness

– Still, misbehaving peers should be logged/displayed to the user

– Otherwise, faults in implementations pass undetected and the overall

compatibility deteriorates

32

• The Internet‘s architecture assumes that packets arrive at their destination if the network is not partitioned

– Allows transient failures of networks, routers, and links

– Connections are not interrupted on intermediate network/link/router failure

Fate Sharing

• Implementing robust state replication to protect against failures in a distributed, global network is extremely hard to achieve

– Only few connection-oriented networks provide this type of robustness

– These are typically operated by a single entity

• Fate Sharing

– It is acceptable that connection state is dropped when the entity that created this connection also fails

– Assumes that no state (about a connection) is stored in the network

33

• Advantages

– Protects network connections against failure of intermediate

routers/links/networks

– Quite easy to implement compared to a resilient, redundant distributed

system

Fate Sharing: Advantages & Consequences

system

• Consequences

– Routers must not have any (essential) state about a connection

– Routers are therefore stateless packet forwarders

� packet switching vs. circuit switching

– Hosts (not the network) are responsible for maintaining the proper

connection state and for delivering a predictable, reliable service to the

applications

34

“The function in question can completely and correctly beimplemented only with the knowledge and help of theapplication standing at the end points of the communicationsystem.

End-to-end Principle

35

Therefore, providing that questioned function as a feature ofthe communication system itself is not possible.

(Sometimes an incomplete version of the function provided bythe communication system may be useful as a performanceenhancement.)”

[saltzer84endtoendargument]

• Example: Reliable file transfer– Task: Transfer a file from Host A to Host B

– Question: How to guarantee reliable delivery?

– What are the concerns when designing such an application?

E2E Principle: Example: Reliable file transfer

36

A B

- File read from disk may be corrupt (hardware fault)

- Software (OS, network stack, application) may be faulty

- Router might crash

- Software bugs (data corruption)

- Processor/Memory may have (transient) faults

Link might:

- drop or duplicate messages

- modify payload

- fail

- Similar to A

• Procedure

– Host A: Read file from disk, packetize and transmit

– Host B: Receive packets, store to hard disk

– Question: How to provide reliability?

E2E Principle: Example: Reliable file transfer

• Option 1 (E2E)

– Given: Correct file checksum at Host A

– Transfer file and checksum from A to B, validate checksum at Host B

– On failure, retransmit file

• Option 2 (Link-by-Link)

– Network provides guarantees on each link (using duplicate copies, error

detection, timeouts, retries, etc.)

37

• Assumption: Errors occur with low probability

• Option 1 (E2E)– With low error probabilities, this technique works well

• Option 2 (Link-by-Link)

E2E Principle: Example: Reliable file transfer

• Option 2 (Link-by-Link)– Requires error-free implementations on each intermediate router � hard

– High effort (� cost, resources) on routers despite low error probability

– Eliminates only on-link errors (not router- or host-related problems)

– Still, the application must do e2e checksum validation (and retransmission upon failure)

• Issues with Option 2– Duplicate functionality (host application, network)

– Only reduces the frequency of error correction at the application level

38

• Option 1 performance drops for longer files

• Lower layer functionality can provide performance enhancements

– Providing full reliability can be costly (retransmissions, timers, etc.)

� performance penalty (bandwidth, CPU, …)

E2E Principle: Example: Reliable file transfer

� performance penalty (bandwidth, CPU, …)

– No perfect reliability is required � Reduced effort in lower layers

• Complex performance trade-off

– Higher reliability vs. complex routers

• Engineering challenges

– Which layer does performance enhancement?

– Don’t over-engineer: Applications still perform e2e checks anyway!

39

• Delivery guarantees

– Delivery notification (from the network) not as important as “job

accomplished” (from the application)

– Applications must provide this end-to-end (Two phase commit)

E2E Principle: Other examples

• Secure data transmission

– Confidentiality only possible end-to-end

• Duplicate message suppression

– Applications may still send duplicates by mistake � Applications

must perform duplicate suppression

40

• Identifying the ends

– Voice over IP: Functionality on lower layers may strongly degrade the

application’s performance (due to retransmissions, in-order delivery, etc.)

– Not a property of voice (think of podcasts) � highly application specific

• Not an absolute guideline, more a rationale for placing functionality in the

End-to-end Principle: Summary

• Not an absolute guideline, more a rationale for placing functionality in the

upper layers of a communication stack

– Goal: Put it closer to the application that uses this functionality

• Problem

– Networks are designed before the applications

– Temptation to put functionality into the network in anticipation of applications

requiring it (consider ISDN)

– Knowledge about E2E may help to reduce this urge

41

• [berners-lee99weavingtheweb] Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web by Its Inventor, Berners-Lee, Tim and Fischetti, Mark, Harper San Francisco, 1999

• [deering01watchingthewaist] Watching the Waist of the Protocol Hourglass (IETF 51, London), http://www.iab.org/documents/docs/hourglass-london-ietf.pdf

Literature

ietf.pdf

• [clark88designinternet] The design philosophy of the DARPA internet protocols, Clark, D., SIGCOMM '88: Symposium proceedings on Communications architectures and protocols, 1988, http://doi.acm.org/10.1145/52324.52336

• [saltzer84endtoendargument] End-to-End Arguments in System Design, Saltzer, J. and Reed, D. and Clark, D.D., ACM Transactions on Computer Systems, 1984, http://web.mit.edu/saltzer/www/publications/endtoend/endtoend.pdf

42

• RFC1958: Architectural Principles of the Internet, https://www1.ietf.org/rfc/rfc1958.txt

• [clark88designinternet] The design philosophy of the DARPA internet protocols, Clark, D., SIGCOMM '88: Symposium proceedings on Communications architectures

To by read by the audience

Symposium proceedings on Communications architectures and protocols, 1988, http://doi.acm.org/10.1145/52324.52336

• [saltzer84endtoendargument] End-to-End Arguments in System Design, Saltzer, J. and Reed, D. and Clark, D.D., ACM Transactions on Computer Systems, 1984, http://web.mit.edu/saltzer/www/publications/endtoend/endtoend.pdf

43