Defining High-Speed Protocols: Five Challenges and an Example that Survives the Challenges Joseph D. Touch IEEE Journal on Selected Areas in Communications May 1995 Presented by 李孝治

I. Introduction At the first IEEE Gigabit Networking (GBN) Workshop held prior to IEEE Infocom’94, a number of “gigabit applications” were presented. The criteria for “gigabit applications” were defined in the call-for-papers by a list of characteristics that ensures –that significant user bases exits and –that a gigabit network is required.

Two primary issues for gigabit protocols –increased speed or performance of existing protocols –domains where existing protocols may not suffice* (* what this paper is concerned with) This paper –summarizes the GBN criteria –justifies the need for additional challenges –presents the challenges –presents an application that survives these challenges

A. The GBN Criteria - a Review 1) Realistic consumer or business application (current or future). 2) Minimum bandwidth per user of many megabits per second. 3) Minimum potential base of thousands of simultaneous users. 4) Number of users  application bandwidth in excess of Tb/s. 5) Consumer video applications must be more sophisticated that broadcast or simple video-on- demand multicast.

Criteria 1 to 4 –Ensure that the application addresses substantial user communities and requires GBN Criteria 5 –Filters those applications that can already be implemented with existing protocols. –But dose not sufficiently exclude classes of gigabit application for which solutions already exist.  Goal: to define a set of criteria that require new protocols to use gigabit networking for real applications.

B. The killer Application and Killer Protocol An application that exhibits the goal: –World Wide Web client-server system with real-time interactive constraints.  – “WWWia” (WWW interactive applications) – (Satisfying Criteria 1) WWW is emerging as a dominant consumer and business application.

–WWW demands response time in the range of ms. –Consider: 100 ms transmission and switching latency 50 ms request/response processing 10 ms for other components  40 ms remain for file transmission.  For a 60 KB image  12 Mbps is needed. For a 200 KB still image  40 Mbps is needed. –(Satisfying Criteria 2) For larger file size and interactive case, the minimum bandwidth per user needs many megabits per second.

–(Satisfying Criteria 3) Minimum potential base of thousands of simultaneous users –(Satisfying Criteria 4) Aggregate bandwidth in excess of Tbps. –(Satisfying Criteria 5) Can existing protocol still be working?

C. Other Considerations WWW bandwidth need

C. Other Considerations To use unused bandwidth to reduce latency Bandwidth-delay product pipe –Vertical pipe (higher BW  tall pipe) –Horizontal pipe (lower BW  longitudinal pipe) B*D t Unused B*D t Unused

II. Primary Issues Two primary issues - A. Protocol Dose Not Run Fast Enough B. The Pipe is Not Kept Full –Note: The Pipe = bandwidth-delay product pipe

A. Protocol Dose Not Run Fast Enough –1) Data Path Is Not Fast To increase the clock rate of the data  To parallelize the data path –2) Control Path Is Not Fast To reduce the amount of control required To slow down the control –to make data packets (payload) larger  –to transmit multiple packets per control packet –3) End-to-End Latency Is Too Large To relocate everything  –To use caching –To circulate the data

B. The Pipe is Not Kept Full –When BD product  current WAN, speed is the issue –When BD product  current WAN, keeping the pipe full is the issue –1) The Pipe Is Empty. Because the Window Is Small To increase the window size  –2) Even with Large Windows, There Is Not Enough Stuff To use multiplexing to share the channel among processes 

III. Five Challenges #1 Increase the Clock Rate #2 Multiplex (Deterministic) #3 Use Large Payload #4 Increase Windows Size #5 Relocate Everything

IV. WWW Interactive Applications Goal: –Use bandwidth-delay product to reduce perceived latency Began as Mirage/Parallel Communication Latency compensation is done by – “source-based anticipation” (pre-sending) not by “receiver-base anticipation” (pre-fetching) –Advantage of pre-sending over pre-fetching distribution of computing avoid unnecessary pre-fetch better use of asymmetric communication channels

V. Defining Characteristics #1 Requires Feedback –Server keeps soft-state #2 “Nonlinear” Communication –non-deterministic –branching #3 “Well-Defined App.-App. BW

VI. An Example That Survives the Challenges (1) A. Survival –1) Increase the clock rate –2) Use deterministic multiplexing –3) Use Large payload –4) Speed TCP code/increase TCP windows –5) Requests feedback

VI. An Example That Survives the Challenges(2) B. Exhibits Characteristics –1) Requires feedback –2) “Nonlinear” communication –3) “Well-defined” app.-app. bandwidth

VII. WWWia’s Architecture Augmenting the exsisting WWW client/server with presenting pump and browser filter.

The pump and the filter together appear as a proxy cache to the client and server.

VIII. Observations Measured on current Web design. ISDN lines: –14% hit rate in 0.1 sec. with plain server –83% hit rate in 0.1 sec. with server pre- loading

No. of HREF’s vs Percentage of HTML pages

Presentable HTML pages vs. additional BW required

VIII. Observations (1) A. Performance –channel utilization goal: 50% (½ request + ½ response)  100% –effective bandwidth goal:  (½ request + ½ response) –effective latency reduced (by guessed messages) –overall cost in terms of “Bandwidth” acceptable -

VIII. Observations (2) B. Bandwidth Requirements –preload should be “droppable available-bit- rate” available-bit-rate: bandwidth is shared preemptive packet scheduler

VIII. Observations (3) C. Other Requirements –availability of sufficient cache storage at receiver: cache space = 1 Bandwidth-delay product at server: cache space  server overload, internal BW –availability of sufficient information independent of user/user history limited to the URL’s within links on one page

IX. Conclusion Five challenges for gigabit applications – that indicate where existing protocols may not work, and where new protocols are required. Interactive real-time WWW access –interactive distributed multimedia access –a class of applications that survive the challenges Source presenting (preloading) –to use excess bandwidth-delay product to reduce the browser response time. –a truly gigabit protocol