Application LayerTCP Throughput on a Congested LinkExpected TCP ThroughputThroughput Dependence on RTTSlide 5“Analysis”Lessons from this ExampleApplication architecturesClient-server architecturePure P2P architectureHybrid of client-server and P2PApp-layer protocol definesWhat transport service does an app need?Transport service requirements of common appsWeb and HTTPHTTP overviewHTTP overview (continued)HTTP connectionsPersistent HTTPHTTP request messageHTTP request message: general formatHTTP response messageTrying out HTTP (client side) for yourselfDNS: Domain Name SystemDNSDistributed, Hierarchical DatabaseDNS: Root name serversTLD and Authoritative ServersLocal Name ServerExampleRecursive queriesDNS: caching and updating recordsDNS recordsDNS protocol, messagesSlide 35Inserting records into DNSFTP: the file transfer protocolFTP: separate control, data connectionsFTP commands, responsesElectronic MailElectronic Mail: mail serversElectronic Mail: SMTP [RFC 2821]Scenario: Alice sends message to BobSample SMTP interactionTry SMTP interaction for yourself:SMTP: final wordsMail access protocolsPOP3 protocolPOP3 (more) and IMAPApplication LayerTCP Throughput on a Congested LinkWhat assumption was made for fairness?At equilibrium, AIMD growth and backoff go in opposite directionsBackoff always goes toward originWhat about growth (i.e., does it always have slope 1)?equal bandwidth sharethroughput 2throughput 1Expected TCP ThroughputNO!Additive increase adds fixed amount per RTTThroughput growth is proportional to 1/RTTFor two-flow case, slope is RTT1/RTT2Analysis with many flowsBottleneck capacity CRates grow to bottleneck, then all back off at onceTotal rate of throughput growth is fixed, so time t between backoffs is also fixedGrowth for each flow is t/RTT, and throughput is proportional to this growthThroughput Dependence on RTT0.010.111 10RTT (arbitrary units)throughput (arbitrary units)1/RTT curve1/sqrt(RTT) curvesimulation scenario 1simulation scenario 2Throughput Dependence on RTTWhat’s going on?Assumed all flows back off under contention(arguably) more likely that only one flow backs offProbability of congestion packet loss is proportional to throughputIntuitionLow-RTT flow is more likely to back offReduces throughput advantage of low-RTT flows“Analysis”Consider a flow F among many, varied flowsBackoffs happen very frequentlyProbability to back off proportional to rateCould happen any timeApproximate by Poisson processLet flow F have expected throughput CExp. time between backoffs proportional to 1/CBetween backoffs, throughput changesfrom 2/3 C to 4/3 C (average is C)Rate of change proportional to C2Rate of change also proportional to 1/RTTThus C proportional to 1/sqrt(RTT)Lessons from this ExampleAnalysisOnly as good as your understandingEasy to shortcut steps when you know the answer (non-rigorous math is not uncommon)SimulationNo better than analysis with regard to understandinge.g., a simulator that backs off all flows achieves throughput proportional to 1/RTTExperiments are necessary!(but can be hard to set up)8Application architecturesClient-serverPeer-to-peer (P2P)Hybrid of client-server and P2P9Client-server architectureserver: always-on hostpermanent IP addressserver farms for scalingclients:communicate with servermay be intermittently connectedmay have dynamic IP addressesdo not communicate directly with each other10Pure P2P architectureno always-on serverarbitrary end systems directly communicatepeers are intermittently connected and change IP addressesexample: GnutellaHighly scalable but difficult to manage11Hybrid of client-server and P2PInstant messagingChatting between two users can be P2PPresence detection/location centralized:User registers its IP address with central server when it comes onlineUser contacts central server to find IP addresses of buddiesNapsterDirectory of files was centralized Transfer of files was P2PScalability problems in the directory12App-layer protocol definesTypes of messages exchanged, e.g., request, response Message syntax:what fields in messages & how fields are delineatedMessage semantics meaning of information in fieldsRules for when and how processes send & respond to messagesPublic-domain protocols:defined in RFCsallows for interoperabilitye.g., HTTP, SMTPProprietary protocols:e.g., Skype13What transport service doesan app need?Data losssome apps (e.g., audio) can tolerate some lossother apps (e.g., file transfer, telnet) require 100% reliable data transfer Timingsome apps (e.g., Internet telephony, interactive games) require low delay to be “effective”Bandwidth□some apps (e.g., multimedia) require minimum amount of bandwidth to be “effective”□other apps (“elastic apps”) make use of whatever bandwidth they 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 above few kbps upelasticTime Sensitivenononoyes, 100’s msecyes, few secsyes, 100’s msecyes and no15Web and HTTPFirst some jargonWeb page consists of objectsObject can be HTML file, JPEG image, Java applet, audio file,…Web page consists of base HTML-file which includes several referenced objectsEach object is addressable by a URLExample URL:http://www.someschool.edu/someDept/pic.gifhost namepath name16HTTP overviewHTTP: hypertext transfer protocolWeb’s application layer protocolclient/server modelclient: browser that requests, receives, “displays” Web objectsserver: Web server sends objects in response to requestsHTTP 1.0: RFC 1945HTTP 1.1: RFC 2068PC runningFirefoxServer runningApache WebserverMac runningSafariHTTP requestHTTP requestHTTP responseHTTP response17HTTP overview (continued)Uses TCP:client initiates TCP connection (creates socket) to server, port 80server accepts TCP connection from clientHTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)TCP connection closedHTTP is “stateless”server maintains no information about past
View Full Document