CompSci 514: Computer Networks Lecture 04: Evolution of the - - PowerPoint PPT Presentation

CompSci 514: Computer Networks Lecture 04: Evolution of the Internet

Xiaowei Yang xwy@cs.duke.edu

Review of the End-to-End Arguments

§ Extremely influential § …functions placed at the lower levels may be redundant or of little value when compared to the cost of providing them at the lower level… § …sometimes an incomplete version of the function provided by the communication system (lower levels) may be useful as a performance enhancement…

Exception: Performance enhancement

§ put into reliability measures within the data communication system is seen to be an engineering tradeoff based on performance, rather than a requirement for correctness.

Performance tradeoff is complex

§ Example: reliability over a lossy link using retries

§ One in a hundred packets will be corrupted § 1K packet size, 1M file size § Probability of no end-to-end retry: (1-1/100)1000 is about 4.3e-5

Today

§ Tussle: how much the Internet has changed, future Internet design goals

§ Tussle in Cyberspace: Defining Tomorrows Internet

§ Integrated layer processing and Application Level Framing

§ Architectural Considerations for a New Generation of Protocols by Clark and Tennenhouse

Problem: Tussles emerge

§ Tussle: The Internet has got into mainstream. Different stakeholders have conflicting interests, each competing to favor their interests § Position: Internets technical design must accommodate this tussle § Question to ponder: what requires technical solutions? And what call for human solutions such as legislation?

Stake holders in the Internet landscape

§ Users: good and bad § ISPs § Private sector network providers § Governments § Intellectual property rights holders § Content and high-level service providers

Different nature of engineering and society

§ Engineering

§ Design for predictable outcomes

§ Society

§ A playground governed by rules, laws, shared values, etc.

§ Challenges

§ How to design the Internet to accommodate the conflicting interests of various stakeholders

§ Suggestion

§ Design it more like a playground with isolated tussle boundaries and ways for users to make choices

Examples of conflicting interests

§ RIAA versus music lovers § ISPs: must inter-connect yet compete

§ Wars of peering and depeering

§ Can you think of other examples?

Principle: design for variation in

• utcome

§ Motivation

§ Old design dictates outcome § It will fail in the new world because a single outcome may only favor one party

§ Design principles that might address the tussle challenge

§ Tussle isolation: modularize along tussle boundaries so that one tussle does not interfere with other tussle

§ DNS: tussle of trademarks spills over tussle for machine names § Question: Is it always possible?

§ Design for choice: permit different players to express their preferences

Implications of the design principles

§ Open interfaces

§ Allow competition of variety of implementations § Allow for choices

§ Tussle over interfaces

§ Conflicting choices

§ Visibility of choices matters § Different flavors of tussles: win-win, win-lose… § Tussles evolve: act, and then counter act § No value-neutral design: what tussles can be played

• ut is built into the design

§ Do not design answers

Example of Tussles: economics

§ Provider lock-in addresses make switching providers a hassle § Support or protect against value pricing?

§ Net neutrality debate

§ Tussle over open access on residential broadband service § No isolation between competition in wide and local provider markets

Tussle of Trust

§ Users do not trust each other § Bad guys want to talk to good users

§ Directions for research

§ Whom to trust, and how to control to whom to talk

§ Spyware wants to collect user information § Identity versus anonymity

Tussle of openness

§ Open is critical to innovation and common wealth § Bad for competition

Revisiting old designs

§ End-to-end implies transparency, which conflicts lost of trust

§ How to keep the network open without transparency?

§ Separation of policies and mechanisms

§ No pure separation, because mechanisms define the supported set of policies

Design lessons

§ Failures of QoS

§ Does not recognize the conflicting interests of different players

§ How will an ISP be paid

§ When design a new enhancement, be incentive-compatible:

§ Recognize the players and their interests § Provide incentives for each side to comply

Today

§ Tussle: how much the Internet has changed, future Internet design goals

§ Tussle in Cyberspace: Defining Tomorrows Internet

§ Integrated layer processing and Application Level Framing

§ Architectural Considerations for a New Generation of Protocols by Clark and Tennenhouse

Architectural principles for better performance

§ Integrated Layer Processing

§ Layering is a design concept § And may not be the most effective modularity for implementation

§ Application Level Framing

§ Get data to applications as soon as possible, in a manner the applications can cope with

Background

§ The paper was written in very old time. Back then

§ The fate of ATM and OSI were unclear § Authors were trying to figure out how to unite IP network and ATM network § We did not know how to write networking code efficiently

Structuring principle of protocol design

§ OSIs 7-layer architecture

§ Physical, data-link, network, transport, session, presentation, application

§ Internet architecture

§ Host-to-network, IP, transport, application

§ Layering is a design choice to decompose complex protocol into functional modules § Should not constrain efficient implementation

Protocol functions

§ What are protocols for?

§ Transfer application information among machines

§ Involving multiple data manipulation steps

Integrated layer processing

§ Multiple data touches are expensive

§ Gap between processor/memory speed

§ Example: copy + checksum

§ Combining the two get 90Mbps

§ Solution: reduce multiple data touches. Do it in

• ne loop if possible

ILP: todays View

§ Network is usually the bottleneck § Application is the bottleneck: presentation conversion § Automatically generating ILP code is hard

§ Many approaches: compiler support, formal languages § None of them really worked

§ ILP leverages special coding techniques such as hand-coded unrolled loops

§ Loss of generality § Code is difficult to understand and maintain

Application Level Framing: Original Motivation

§ Presentation conversion is the bottleneck

§ ASN.1 Integer to ASCII: 28Mb/s § Copy: 130Mb/s; Checksum: 115Mb/s

§ 97% of the overhead was attributed to the presentation conversion § Solutions

§ Eliminate presentation conversion: ASCII protocols § Optimize

ALF: the problem

§ TCP”s reliable in-order byte-stream interface prohibits the out of order data delivery to application § Application is prevented from performing presentation conversion as data arrives § Since presentation conversion is the bottleneck, it will fall behind forever § à Allow data manipulation to happen in the presence of mis-ordered and lost packets § Out of order data manipulation improves performance even when presentation conversion is absent

ALF: why

§ General requirements for out of order processing

§ “synchronization points” in data streams

§ Example: checksums are computed on per packet basis. Packet boundary serves as synchronization points § Synchronization points have to make sense to applications

§ TCP numbers the bytes in the data stream, which has no meaning to applications § Presentation changes the application data format and does not preserve the size

ALF: what

§ ALF

§ Lower layers deal with data in units the application specifies § Applications are encouraged to deal with data loss and data recovery in their preferred fashion

§ Selective reliability, out of order processing

§ Application Data Unit (ADU)

§ The smallest data unit that an application can process out of order

ALF: what (cont.)

....

1

B3

2

B

N I C

Serial to Parallel

TCP IP APP Application Memory Kernel Memory Device Memory Byte stream B Host to

Network

APP

DATA TAG

ADU Protocol Stack (?)

ALF: how

§ Receiver needs to understand where to put ADUs and what to do with them § Sender can compute a name for each ADU: a meta data that tags the ADU § The name permits the receiver to understand its place in the sequence of ADUs

Example I: Image Transport Protocol (ITP)

§ Problem

§ Images account for much of today’s Internet traffic § Image transport is over HTTP/TCP § TCP’s in order delivery results in poor latency in lossy networks

§ Solution

§ Image data is structured § Frame data into micro blocks (ADUs) § Deliver and process ADUs out of order § Interpolate missing ADUs

ITP performance

Example II: ALF in Reliable Multicasting

§ Difficulties in achieving scalable reliable multicasting: ACK implosion § Scalable reliable multicasting (SRM)

§ Senders compute meta-data that summarizes all available data § Receivers request retransmission of any desired data triggered by meta-data using multicasting damping

Scalable data naming to express semantics

§ Problem:

§ Traditional reliable protocols number data units sequentially to detect losses § Transport-level sequence numbers do not express applications reliability semantics

§ wb: sequence number 5000 is associated with page 10 § Receiver-driven reliability is cumbersome to achieve

§ Solution

§ A data naming scheme to expose the structure of application data to transport layer § A receiver is able to express its reliability semantics to the transport layer

Scalable naming and announcement protocol: hierarchical data naming

§ Allow senders to transmit different objects independently § Allow receivers to easily specify the data it requires § The meta-data is scalable even when the data set is large

Example: an ADU from wb

§ The 5th drawing operation on page 2 from source 9

Comments on ALF

§ Good for interactive applications, where user perceivable performance matters § Good for graphical applications, where data are inherently multi-dimensional

The paper’s influence

§ Inspired three trends of research

§ A new protocol stack: a debatable issue

§ ALF == UDP + application specific protocols?

?

IP

Ethernet Dialup ....... Packet Radio TCP UDP .......... FTP, Telnet, Email...... FTP, Telnet, Email...... ADU layer

IP, ATM

Ethernet Dialup ....... Packet Radio

The paper’s influence

§ Inspired three trends of research § A new protocol stack: a debatable issue § Protocol implementation

§ Specialized protocol implementation (e.g, TCP for telnet) § Lessons: taking into account Moore’s law for performance optimization § ALF based applications and protocols: the most successful branch

§ ITP, wb, reliable multicasting § Future: Google’s QUIC protocol

Summary

§ Tussle arises § ILP and ALF briefly visited § Next week: Congestion control