Packet Loss Internet Protocol Stack Chapter 2: Application Layer

Last Course Review: Delay in packet-switched networks Four sources of packet delay 3. Transmission delay: 4. Propagation delay: R=link bandwidth (bps) d = length of physical link 1. nodal processing: 2. queueing s = propagation speed in check bit errors time waiting at output L=packet length (bits) 8 determine output link link for transmission time to send bits into medium (~2x10 m/sec) deppgends on congestion link = L/R pppgropagation delay = d/s level of router

transmission Note: s and R are very A different quantities! propagation transmission A propagation B nodal processing queueing B nodal processing queueing Introduction 1-1 Introduction 1-2

Packet loss Internet protocol stack

application: supporting network queue (aka buffer) preceding link in buffer applications application has finite capacity FTP, SMTP, STTP when packet arrives to full queue, packet is transport: host-host data transfer transport dropped (aka lost) TCP, UDP lost packet may be retransmitted by network: routing of datagrams from network source to destination previous node, by source end system, or IP, routing protocols link not retransmitted at all link: data transfer between neighboring network elements physical PPP, Ethernet physical: bits “on the wire”

Introduction 1-3 Introduction 1-4

Chapter 2: Application layer Chapter 2: Application Layer

Our goals: learn about protocols 2.1 Principles of conceptual, by examining popular network applications implementation application-level 2.2 Web and HTTP aspects of network protocols 2.3 FTP application protocols HTTP 242.4 Elect ron ic Ma il transport-layer FPFTP SMTP, POP3, IMAP service models SMTP / POP3 / IMAP DNS 2.5 DNS client-server 2.6 P2p file sharing paradigm peer-to-peer paradigm

Introduction 1-5 Introduction 1-6

1 Some network apps Creating a network app

application Write programs that transport E-mail Internet telephone network run on different end data link Web Real-time video systems and physical Instant messaging conference communicate over a network. Remote login Massive parallel computing e.g ., Web: Web server P2P file sharing software communicates Multi-user network with browser software

games No software written for application application transport devices in network core transport network Streaming stored network data link data link physical video clips Network core devices do physical not function at app layer This design allows for rapid app development

Introduction 1-7 Introduction 1-8

Chapter 2: Application layer Application architectures

2.1 Principles of 2.6 P2P file sharing Client-server network applications Peer-to-peer (P2P) 2.2 Web and HTTP Hybrid of client-server and P2P 2.3 FTP 242.4 Elect ron ic Ma il SMTP, POP3, IMAP 2.5 DNS

Introduction 1-9 Introduction 1-10

Client-server archicture Pure P2P architecture

server: no always on server always-on host permanent IP address arbitrary end systems server farms for scaling directly communicate clients: peers are intermittently communicate with connected and change IP server addresses may be intermittently example: BitTorrent, connected Gnutella may have dynamic IP addresses do not communicate Highly scalable directly with each other But difficult to manage

Introduction 1-11 Introduction 1-12

2 Hybrid of client-server and P2P App-layer protocol defines

Napster Types of messages Public-domain protocols: File transfer P2P exchanged, eg, request defined in RFCs File search centralized: & response messages allows for • Peers register content at central server Syntax of message interoperability • Peers query same central server to locate content types: what fields in eg, HTTP, SMTP Instant messaging messages & how fields Proprietary protocols: Chatting between two users is P2P are delineated eg, KaZaA Presence detection/location centralized: Semantics of the • User registers its IP address with central server fields, ie, meaning of when it comes online information in fields • User contacts central server to find IP addresses of buddies Rules for when and how processes send &

Introduction 1-13 respond to messages Introduction 1-14

What transport service does an app need? Transport service requirements of common apps

Data loss Bandwidth Application Data loss Bandwidth Time Sensitive some apps (e.g., audio) can some apps (e.g., tolerate some loss multimedia) require file transfer no loss elastic no other apps (e.g., file minimum amount of e-mail no loss elastic no transfer, telnet) require bandwidth to be Web documents no loss elastic no 100% reliable data yes, 100’ ssmsec msec “ff“effective” real-time audio/video loss-tltoleran t audio: 5kbps-1Mbps transfer video:10kbps-5Mbps other apps (“elastic stored audio/video yes, few secs Timing loss-tolerant same as above apps”) make use of interactive games loss-tolerant few kbps up yes, 100’s msec some apps (e.g., whatever bandwidth instant messaging no loss elastic yes and no Internet telephony, they get interactive games) require low delay to be “effective”

Introduction 1-15 Introduction 1-16

Internet transport protocols services Internet apps: application, transport protocols

Application UDP service: Underlying TCP service: Application layer protocol transport protocol connection-oriented: setup unreliable data transfer required between client and between sending and e-mail SMTP [RFC 2821] TCP server processes receiving process remote terminal access Telnet [RFC 854] TCP reliable transport between does not provide: Web HTTP [RFC 2616] TCP sending and rece iv ing process connection setup, file transf er FTP [RFC 959] TCP flow control: sender won’t reliability, flow control, streaming multimedia proprietary TCP or UDP overwhelm receiver congestion control, timing, (e.g. RealNetworks) or bandwidth guarantee Internet telephony proprietary congestion control: throttle (e.g., Dialpad) typically UDP sender when network overloaded Q: why bother? Why is does not provide: timing, there a UDP? minimum bandwidth guarantees

Introduction 1-17 Introduction 1-18

3 Chapter 2: Application layer Web and HTTP

2.1 Principles of 2.6 P2P file sharing First some jargon network applications Web page consists of objects app architectures Object can be HTML file, JPEG image, Java app requirements applet, audio file,… 2. 2 Web and HTTP WbWeb page consiitsts of base HTML-file which 2.4 Electronic Mail includes several referenced objects SMTP, POP3, IMAP Each object is addressable by a URL 2.5 DNS Example URL: www.someschool.edu/someDept/pic.gif

host name path name

Introduction 1-19 Introduction 1-20

HTTP overview HTTP overview (continued)

HTTP: hypertext Uses TCP: HTTP is “stateless” transfer protocol client initiates TCP server maintains no Web’s application layer PC running connection (creates socket) information about protocol Explorer to server, port 80 past client requests client/server model server accepts TCP connection from c lien t aside client: browser that Protocols that maintain requests, receives, Server HTTP messages (application- “state” are complex! “displays” Web objects running layer protocol messages) past history (state) must Apache Web exchanged between browser server: Web server be maintained server (HTTP client) and Web sends objects in if server/client crashes, server (HTTP server) response to requests their views of “state” may Mac running TCP connection closed HTTP 1.0: RFC 1945 Navigator be inconsistent, must be HTTP 1.1: RFC 2068 reconciled

Introduction 1-21 Introduction 1-22

HTTP connections Nonpersistent HTTP (contains text, Suppose user enters URL references to 10 www.someSchool.edu/someDepartment/home.index jpeg images) Nonpersistent HTTP Persistent HTTP At most one object is Multiple objects can 1a. HTTP client initiates TCP connection to HTTP server sent over a TCP be sent over single 1b. HTTP server at host (process) at www.someSchool.edu waiting connection. TCP connection www.someSchool.edu on port 80 between client and for TCP connection at port 80. HTTP/1. 0 uses “accepts” connection, notifying nonpersistent HTTP server. client 2. HTTP client sends HTTP HTTP/1.1 uses request message (containing persistent connections URL) into TCP connection 3. HTTP server receives request in default mode socket. Message indicates message, forms response that client wants object message containing requested someDepartment/home.index object, and sends message into its socket time Introduction 1-23 Introduction 1-24

4 Nonpersistent HTTP (cont.) Response time modeling

Definition of RTT: time to 4. HTTP server closes TCP connection. send a small packet to 5. HTTP client receives response travel from client to message containing html file, server and back. initiate TCP displays html. Parsing html connection file, finds 10 referenced jpeg Response time: RTT objects request time one RTT to initiate TCP 6. Steps 1-5 repeated for each file connection time to of 10 jpeg objects RTT transmit one RTT for HTTP file request and first few file received bytes of HTTP response

to return time time file transmission time total = 2RTT+transmit time Introduction 1-25 Introduction 1-26

Persistent HTTP HTTP request message

Nonpersistent HTTP issues: Persistent without pipelining: requires 2 RTTs per object client issues new request two types of HTTP messages: request, response OS must work and allocate only when previous HTTP request message: host resources for each TCP response has been received ASCII (human-readable format) connection one RTT for each but browsers offpten open referenced object request line parallel TCP connections to Persistent with pipelining: (GET, POST, GET /somedir/page.html HTTP/1.1 fetch referenced objects default in HTTP/1.1 HEAD commands) Host: www.someschool.edu Persistent HTTP client sends requests as User-agent: Mozilla/4.0 header Connection: close server leaves connection soon as it encounters a lines open after sending response referenced object Accept-language:fr subsequent HTTP messages as little as one RTT for all Carriage return, (extra carriage return, line feed) between same client/server the referenced objects line feed are sent over connection indicates end of message Introduction 1-27 Introduction 1-28

HTTP request message: general format Uploading form input

Post method: Web page often includes form input URL method: Input is uploaded to Uses GET method server in entity body ItInput is uplddloaded in URL field of request line:

www.somesite.com/animalsearch?monkeys&banana

Introduction 1-29 Introduction 1-30

5 Method types HTTP response message

status line HTTP/1.0 HTTP/1.1 (protocol GET GET, POST, HEAD status code HTTP/1.1 200 OK status phrase) Connection close POST PUT Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) HEAD uploads file in entity header body to path specified Last-Modified: Mon, 22 Jun 1998 …... asks server to leave lines in URL field Content-Length: 6821 requested object out of Content-Type: text/html response DELETE deletes file specified in data, e.g., data data data data data ... the URL field requested HTML file

Introduction 1-31 Introduction 1-32

HTTP response status codes

In first line in server->client response message. A few sample codes: 200 OK request succeeded, requested object later in this message 301 Moved Permanently requested object moved, new location specified later in this message (Location:) 400 Bad Request request message not understood by server 404 Not Found requested document not found on this server 505 HTTP Version Not Supported

Introduction 1-33