1 / 15

also available in Microsoft PowerPoint

Success disaster for both the Internet and the Web. Conservatively, we need to scale the Internet/Web 104 higher, even ignoring continuous media ...

Michelle
Download Presentation

also available in Microsoft PowerPoint

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    Slide 1:The Web versus The Internet Presentation for Joint APPS/transport BOF Los Angeles IETF 3/4/96, revised 3/11/96

    Jim Gettys jg@w3.org World Wide Web Consortium Digital Equipment Corporation

    Slide 2:Mutual Coexistence

    The Web is causing the Internet to succeed We don’t want the Internet to die of the Web’s success

    Slide 3:Outline of this Talk

    Problems Solution(s) Call to Action

    Slide 4:Today’s Situation

    Congestion on many links (particularly trans-oceanic) Success disaster for both the Internet and the Web Conservatively, we need to scale the Internet/Web 104 higher, even ignoring continuous media I don’t believe there is a single “magic bullet” to solve the problem

    Slide 5:How Did We Get Here?

    HTTP protocol Feature: simple Bug: simple Fetches single URL per TCP connection Mean size is only a few thousand bytes Bimodal size of URL’s, usually short

    Slide 6:Consequences of HTTP simplicity

    Servers have thousands of connections in time_wait state e.g.. AltaVista server is at > 4 million connections/day, or 50/second averaged over 24 hours Cost is primarily memory, on systems running reasonable TCP implementations Losing congestion information on each URL Poor user perceived performance Netscape multiple connection hack Vanity servers with HTTP result in big servers using 100’s of I.P. addresses, due to oversight in protoocol Connection opens may be congesting low bandwidth links, due to lack of flow control Size of routing tables/routing caches in routers?

    Slide 7:Available Options

    Fix HTTP Replace HTTP 1.X with HTTP-NG Deploy caching Deploy T/TCP Replace TCP with other transport protocol(s) Fix routers to police flows???

    Slide 8:HTTP Fixes Required

    Persistent connections Caching somewhat buggy, due to problems in 1.0 protocol Multiplex the connection to help time to render Host name must accompany request to solve vanity address problem

    Slide 9:Netscape Hack

    Problem: Rendering a page requires meta-data of objects embedded in that page Solution (according to Marc A.): Open N connections simultaneously (by default 4) Result: Faster time to render Self congestion of nearly simultaneous opens “Unfair” use of bandwidth (problem of the “commons”) Has made a bad problem much worse Even with persistent connections, we will have fairness problems for clients that use multiple connections, versus “well behaved” clients using one. RED algorithm in routers may help.

    Slide 10:HTTP-NG

    Preliminary results of (essentially) HTTP 1.X over SCP (mux layer) are very encouraging Simon Spero and Andy Norman’s NG proxy showing good results on transatlantic links (HTTP 1.X encapsulated in NG over SCP) Finishing design will take quite a while Not a short term solution, in my opinion

    Slide 11:Persistent connections

    By itself, I don’t think they will succeed against Netscape hack, as it hurts Time to Render Need multiplexing layer to solve time to render problem (have preliminary design in hand) Prototyping mux layer for HTTP 1.x right now, with provisions for multiple protocols over the same connection, to allow graceful NG transition Transition to a MUX layer has all the same deployment problems of NG, but requires much less work than NG for clients and servers to implement Mux layer can be done quickly

    Slide 12:Caching

    Needs both HTTP fixes and deployment Deployment by ISP’s Benefits: Helps perceived response Gives appearance of more robust system Problems: Don’t expect too much: 60-70% hit rate, but is affected by demographics problems How do you find your cache? Need to be able to autoconfigure caching, due to naďve users Administration hassles?

    Slide 13:T/TCP

    Would help by: Reducing packet exchanges on opens (which are not flow controlled) Reduce latency to end user (bored users == hitting stop buttons on browsers) Is a better match for current HTTP than once persistent connections are deployed A net gain in any case Concerns: uses some state between connections Must understand consequences on big Web server systems Must fully understand congestion consequences, and potential performance cliffs Unlikely to help in short term due to deployment time

    Slide 14:No Magic Bullet Short Term Fixes

    Fix HTTP-1.0 Vanity addresses Caching bugs Persistent connections Should be minimum set of deliverables for HTTP 1.1 Add MUX layer as soon as possible otherwise I expect persistent connections will not succeed in the market Encourage deployment of caching servers at ISP’s Fix economic bugs in Internet traffic Deploy and enable RED algorithm in routers, to help fairness problem

    Slide 15:No Magic Bullet Longer term

    Finish NG work (will help bandwidth and latency over high latency connections) Deploy and use T/TCP for the web Multicast transport with caching might solve “flash crowd” problems Need better name services D&B has 40 million businesses How to find “nearest” cache!?!? Flow policing in routers???? Get Internet transport, Web, and distributed systems people working on longer term solutions

More Related