compsci514: computer networks lecture 04: evolution of the ... · lecture 04: evolution of the...
TRANSCRIPT
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.)
....1 B32B
N I CSerial to Parallel
TCP
IP
APP
ApplicationMemory
Kernel Memory Device Memory
Byte stream
B
Host toNetwork
APP
DATATAG
ADUProtocol 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