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 Tomorrow � s 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: Internet � s 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 outcome § 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 out 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 Tomorrow � s 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 § OSI � s 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 one loop if possible

ILP: today � s 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.) Byte stream B B B 3 .... 1 2 APP TCP N I C Host to IP Network Serial to Parallel Application Memory Kernel Memory Device Memory Protocol Stack ADU APP (?) TAG DATA

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