Application LayerTCP Throughput on aCongested Link What assumption wasmade for fairness? At equilibrium, AIMD growthand backoff go in oppositedirections Backoff always goes towardorigin What about growth (i.e.,does it always have slope1)?equal bandwidthsharethroughput 2throughput 1Expected TCP Throughput NO! Additive increase adds fixed amount per RTT Throughput growth is proportional to 1/RTT For two-flow case, slope is RTT1/RTT2 Analysis with many flows Bottleneck capacity C Rates grow to bottleneck, then all back off at once Total rate of throughput growth is fixed, so time Δt betweenbackoffs is also fixed Growth for each flow is Δt/RTT, and throughput is proportional tothis growthThroughput Dependence onRTTThroughput Dependence onRTT What’s going on? Assumed all flows back off under contention (arguably) more likely that only one flow backs off Probability of congestion packet loss is proportional tothroughput Intuition Low-RTT flow is more likely to back off Reduces throughput advantage of low-RTT flows“Analysis” Consider a flow F among many, varied flows Backoffs happen very frequently Probability to back off proportional to rate Could happen any time Approximate by Poisson process Let flow F have expected throughput C Exp. time between backoffs proportional to 1/C Between backoffs, throughput changesfrom 2/3 C to 4/3 C (average is C) Rate of change proportional to C2 Rate of change also proportional to 1/RTT Thus C proportional to 1/sqrt(RTT)Lessons from this Example Analysis Only as good as your understanding Easy to shortcut steps when you know theanswer (non-rigorous math is not uncommon) Simulation No better than analysis with regard tounderstanding e.g., a simulator that backs off all flows achievesthroughput proportional to 1/RTT Experiments are necessary!(but can be hard to set up)8Application architectures Client-server Peer-to-peer (P2P) Hybrid of client-server and P2P9Client-server architectureserver: always-on host permanent IP address server farms for scalingclients: communicate with server may be intermittentlyconnected may have dynamic IPaddresses do not communicatedirectly with each other10Pure P2P architecture no always-on server arbitrary end systemsdirectly communicate peers are intermittentlyconnected and change IPaddresses example: GnutellaHighly scalable but difficultto manage11Hybrid of client-server andP2PInstant messaging Chatting between two users can be P2P Presence detection/location centralized: User registers its IP address with central server when itcomes online User contacts central server to find IP addresses ofbuddiesNapster Directory of files was centralized Transfer of files was P2P Scalability problems in the directory12App-layer protocol defines Types of messagesexchanged, e.g., request, response Message syntax: what fields in messages &how fields are delineated Message semantics meaning of information infields Rules for when and howprocesses send &respond to messagesPublic-domainprotocols: defined in RFCs allows forinteroperability e.g., HTTP, SMTPProprietary protocols: e.g., Skype13What transport service doesan app need?Data loss some apps (e.g., audio)can tolerate some loss other apps (e.g., filetransfer, telnet) require100% reliable datatransferTiming some apps (e.g.,Internet telephony,interactive games)require low delay tobe “effective”Bandwidth□ some apps (e.g.,multimedia) requireminimum amount ofbandwidth to be“effective”□ other apps (“elasticapps”) make use ofwhatever bandwidththey get14Transport service requirements of common appsApplicationfile transfere-mailWeb documentsreal-time audio/videostored audio/videointeractive gamesinstant messagingData lossno lossno lossno lossloss-tolerantloss-tolerantloss-tolerantno lossBandwidthelasticelasticelasticaudio: 5kbps-1Mbpsvideo:10kbps-5Mbpssame as abovefew kbps upelasticTime Sensitivenononoyes, 100’s msecyes, few secsyes, 100’s msecyes and no15Web and HTTPFirst some jargon Web page consists of objects Object can be HTML file, JPEG image, Javaapplet, audio file,… Web page consists of base HTML-file whichincludes several referenced objects Each object is addressable by a URL Example URL:http://www.someschool.edu/someDept/pic.gifhost namepath name16HTTP overviewHTTP: hypertext transferprotocol Web’s application layerprotocol client/server model client: browser thatrequests, receives,“displays” Web objects server: Web serversends objects inresponse to requests HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068PC runningFirefoxServer runningApache WebserverMac runningSafariHTTP requestHTTP requestHTTP responseHTTP response17HTTP overview (continued)Uses TCP: client initiates TCPconnection (creates socket) toserver, port 80 server accepts TCPconnection from client HTTP messages (application-layer protocol messages)exchanged between browser(HTTP client) and Web server(HTTP server) TCP connection closedHTTP is “stateless” server maintains noinformation about pastclient requestsProtocols that maintain “state”are complex!□ past history (state) must bemaintained□ if server/client crashes, theirviews of “state” may beinconsistent, must bereconciledaside18HTTP connectionsNonpersistent HTTP At most one objectis sent over a TCPconnection. HTTP/1.0 usesnonpersistent HTTPPersistent HTTP Multiple objects canbe sent over singleTCP connectionbetween client andserver. HTTP/1.1 usespersistentconnections indefault mode19Persistent HTTPNonpersistent HTTP issues: requires 2 RTTs per object OS overhead for each TCPconnection browsers often open parallelTCP connections to fetchreferenced objectsPersistent HTTP server leaves connectionopen after sending response subsequent HTTP messagesbetween same client/serversent over open connectionPersistent without pipelining: client issues new requestonly when previousresponse has been received one RTT for each referencedobjectPersistent with pipelining: default in HTTP/1.1 client sends requests assoon as it encounters areferenced object as little as one RTT for allthe referenced objects20HTTP request message Two types of HTTP messages: request, response HTTP request message: ASCII (human-readable format)GET
View Full Document
Unlocking...