Chapter 2

Application
Layer
Application Layer: Principles of Network
Applications, The Web and HTTP, File Transfer: FTP
Commands and Replies, Electronic Mail in the
Computer
Internet, SMTP, POP3, DNS, P2P, Video Streaming, Networking: A
Content Distribution Networking, The Internet's Top Down
Directory Service, Peer-to-Peer Applications-Bit Approach
Torrent File distribution protocol. Domain Name 6th edition
System (DNS) Jim Kurose, Keith
Ross
Addison-Wesley
March 2012

Application Layer 2-1

Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 socket
applications programming
2.2 Web and HTTP with UDP and TCP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-2

Chapter 2: application
layer
our goals:  learn about
 conceptual, protocols by
implementation examining popular
aspects of network application-level
application protocols
protocols  HTTP
 transport-layer  FTP
service models  SMTP / POP3 / IMAP
 client-server  DNS
paradigm  creating network
 peer-to-peer applications
paradigm  socket API

Application Layer 2-3

Some network apps
 e-mail  voice over IP (e.g.,
 web Skype)
 text messaging  real-time video
conferencing
 remote login
 social networking
 P2P file sharing
 search
 multi-user network
games  …
 streaming stored  …
video (YouTube,
Hulu, Netflix)

Application Layer 2-4

Creating a network app application
transport
network
data link
At the core of N/W, app physical

development is to write
programs that:
 run on (different) end
systems
 communicate over network
 e.g., web server software
communicates with
browser software application
transport
network
no need to write software for data link application

network-core devices physical transport

network
data link
 network-core devices do physical

not run user applications

 applications on end
systems allows for rapid
app development,
propagation
Application Layer 2-5
Communication for a network Application takes place between end
systems at the application layer

Application Layer 2-6

Application architectures
Possible structure of applications:
 client-server
 peer-to-peer (P2P)

 Client-server Architecture
 There is an always-on host, called the server, which services requests from many
other hosts, called clients.
 A classic example is the Web application for which an always-on Web server
services requests from browsers running on client hosts.
 When a Web server receives a request for an object from a client host, it
responds by sending the requested object to the client host.
 clients do not directly communicate with each other.
 Another characteristic of the client-server architecture is that the server has a
fixed, well-known address, called an IP address.
 Some of the better-known applications with a client-server architecture include
the Web, FTP, Telnet, and e-mail.

Application Layer 2-7

 Client-server architecture
server:
 always-on host
 permanent IP address
 data centers for
scaling(housing a large number of
hosts, is often used to create a powerful
virtual server. )

clients:
 communicate with server
client/server  may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate
directly with each other

Application Layer 2-8

P2P architecture
 no always-on server peer-peer
 arbitrary end systems
directly communicate
 peers request service
from other peers,
provide service in
return to other peers
 self scalability – new
peers bring new
service capacity, as
well as new service
demands
 peers are intermittently
connected and change
IP addresses
 complex
management Application Layer 2-9
Challenges:
 ISP Friendly: Most residential ISPs (including DSL and
cable ISPs) have been dimensioned for “asymmetrical”
bandwidth usage, that is, for much more downstream
than upstream traffic. But P2P video streaming and file
distribution applications shift upstream traffic from
servers to residential ISPs, thereby putting significant
stress on the ISPs.
 Security. Because of their highly distributed and open
nature, P2P applications can be a challenge to secure.
 Incentives. : Convincing users to volunteer bandwidth,
storage, and computation resources to the applications,
which is the challenge of incentive design.

Application Layer 2-10

(a) Client-server architecture; (b) P2P architecture

Application Layer 2-11

Processes communicating
process: program clients, servers
running within a client process:
host process that initiates
 within same host, two communication
processes server process:
communicate using process that waits to
inter-process be contacted
communication
(defined by OS)  Note: applications
 processes in different with P2P architectures
hosts communicate have client processes
by exchanging & server processes
messages

Application Layer 2-12

Sockets
 process sends/receives messages to/from its socket
 socket analogous to door
 sending process shoves message out door
 sending process relies on transport infrastructure on
other side of door to deliver message to socket at
receiving process
 two sockets involved: one on each side

application application
socket controlled by
process process app developer

transport transport
network network controlled
link
by OS
link Internet
physical physical

Application Layer 2-13

Sockets
 It is the interface between the application layer
and the transport layer within a host.
 Application Programming Interface (API)
between the application and the network,
since the socket is the programming interface
with which network applications are built.
 The application developer has control of
everything on the application-layer side of the
socket but has little control of the transport-
layer side of the socket.
 The only control that the application
developer has on the transport-layer side is (1)
the choice of transport protocol and (2) the
ability to fix a few transport-layer parameters
such as maximum buffer and maximum
segment sizes.
Application Layer 2-14
Once the application developer chooses a
transport protocol (if a choice is available) the
application is built using the transport-layer
services provided by that protocol.

Application Layer 2-15

Addressing processes
 identifier includes both IP address and port
In order to send postal mail to a particular

numbers associated with process on host.
destination, the destination needs to have
an address. example port numbers:


  HTTP server: 80
Similarly, in order for a process running
on one host to send packets to a process
 mail server: 25
running on another host, the receiving
to send HTTP message to

process needs to have an identifier.
[Link] web server:
 Host device has unique 32-bit IP address
 IP address: [Link]
 Q: does IP address of host on which
 port number: 80
process runs suffice for identifying the
 sending process must also identify the
process?
receiving process (more specifically,
 A: no, many processes the receiving socket) running in the
can be running on same host, because in general a host could
be running many network applications.
host A destination port number serves this
purpose.

Application Layer 2-16

App-layer protocol defines
 types of messages open protocols:
exchanged,  defined in RFCs
 e.g., request,  allows for
response
interoperability
 message syntax:  e.g., HTTP, SMTP
 what fields in
messages & how proprietary protocols:
fields are delineated  e.g., Skype
 message semantics
 meaning of
information in fields
 rules for when and how
processes send &
respond to messages

Application Layer 2-17

What transport service does an
app need?
data integrity throughput
 some apps (e.g.,
 some apps (e.g., file
multimedia) require
transfer, web minimum amount of
transactions) require throughput to be
100% reliable data “effective”.
 Eg: internet telephony
transfer  other apps (“elastic apps”)
 other apps (e.g., audio)
make use of whatever
timing
can tolerate some loss throughput they get .
 some apps (e.g., Internet  Eg: E-mail, file transfer, web
telephony, interactive transfer
games) require low delay
to be “effective”. security
 Causes unnatural pauses  encryption, data
in the conversation;
integrity, …
 Long delay makes the
application feel less
realistic.
Application Layer 2-18
 Transport service requirements:
common apps

application data loss throughput time sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
text messaging no loss elastic yes and no

Application Layer 2-19

Internet transport protocols
services
TCP service: UDP service:
 reliable transport  unreliable data
between sending and transfer between
receiving process sending and receiving
 flow control: sender process
won’t overwhelm
receiver
 does not provide:
 congestion control: reliability, flow
throttle sender when control, congestion
network overloaded control, timing,
 does not provide: timing, throughput
minimum throughput guarantee, security,
guarantee, security orconnection setup,
 connection-oriented:
setup required between Q: why bother? Why is
client and server
processes there a UDP?
Application Layer 2-20
Internet apps: application, transport
protocols
application underlying
application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (e.g., YouTube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) TCP or UDP

Application Layer 2-21

Securing TCP[ Secure Socket
Layer]
TCP & UDP SSL is at app layer
 Apps use SSL libraries, which “talk” to
 No encryption TCP
 cleartext passwds sent into socket, SSL socket API
traverse Internet & cleartext pw  cleartext passwds sent into socket
may get sniffed and discovered at
any of the intervening links. traverse Internet encrypted .
 Because privacy and other security  SL has its own socket API that is similar
issues have become critical for to the traditional TCP socket API.
many applications, the Internet  With SSL, the sending process passes
community has developed an cleartext data to the SSL socket; SSL in
enhancement for TCP. the sending host then encrypts the
SSL data and passes the encrypted data to
the TCP socket.
 Provides encrypted TCP
connection.  The encrypted data travels over the
Internet to the TCP socket in the
 data integrity receiving process. The receiving socket
 end-point authentication passes the encrypted data to SSL,
which decrypts the data.

Application Layer 2-22

Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 socket
applications programming
 app architectures with UDP and TCP
 app
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS
Application Layer 2-23
Applications :
Consider Five important applications: the Web, file transfer, electronic mail,
directory service, and P2P applications.
[Link]: Not only is an enormously popular application, but also its application-layer
protocol,
[Link], is straightforward and easy to understand.
[Link], provides a nice contrast to HTTP.
[Link] mail, the Internet’s first killer application. It is more complex than the
Web because it makes use of not one but several application-layer protocols.
[Link], provides a directory service for the Internet. Most users do not interact with
DNS directly; instead, users invoke DNS indirectly through other applications (including
the Web, file transfer, and electronic mail).

Application Layer 2-24

(Web and HTTP)
 Web was the first Internet application that caught the general public’s eye.
 It is enormously easy for any individual to make information available over
the Web—everyone can become a publisher at extremely low cost.
 Web serves as a platform for many killer applications, including YouTube,
Gmail, and Facebook.
 HyperText Transfer Protocol (HTTP) is implemented in two programs:
 A client program and A server program.
 These programs executing on different end systems, talk to each other by
exchanging HTTP messages.

[Link]/someDept/[Link]
host name path name

Application Layer 2-25

 A web page(also known as Document) consists of objects.
 Object can be HTML file, JPEG image, Java applet, audio file,…
 web page consists of base HTML-file which includes several referenced objects
 each object is addressable by a URL, e.g.,

host name path name

 HTTP defines how Web clients request Web pages from Web servers and how
 servers transfer Web pages to clients.

Application Layer 2-26

HTTP request-response
behavior
 When a user requests a Web page (for
example, clicks on a hyperlink), the browser
sends HTTP request messages for the objects
in the page to the server. The server receives
the requests and responds with HTTP response
messages that contain the objects.

Application Layer 2-27

HTTP overview
HTTP: hypertext
transfer protocol
HT
 Web’s application TP
req
layer protocol PC running HT
ues
t
T
 client/server model Firefox browser Pr
esp
ons
 client: browser that e
requests, receives,
(using HTTP t
u es
protocol) and req server
T P n se
“displays” Web HT s po running
re Apache Web
objects T TP
H server
 server: Web server
sends (using HTTP
protocol) objects in iphone running
response to Safari browser
requests

Application Layer 2-28

HTTP overview (continued)
uses TCP: HTTP is “stateless”
 client initiates TCP  server maintains no
connection (creates information about
past client requests
socket) to server, port
80
 server accepts TCP aside
connection from client protocols that maintain
 HTTP messages “state” are complex!
(application-layer  past history (state) must
protocol messages) be maintained
exchanged between  if server/client crashes,
browser (HTTP client) their views of “state”
and Web server (HTTP may be inconsistent,
server) must be reconciled
 TCP connection closed
Application Layer 2-29
HTTP connections
non-persistent HTTP persistent HTTP
 at most one  multiple objects
object sent over can be sent over
TCP connection single TCP
 connection then connection
closed between client,
 downloading server
multiple objects
required multiple
connections

Application Layer 2-30

 Non-persistent HTTP
suppose user enters URL: (contains text,
[Link]/someDepartment/[Link] references to 10
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server
(process) at 1b. HTTP server at host
[Link] on [Link]
port 80 waiting for TCP connection
at port 80. “accepts”
2. HTTP client sends HTTP request message
connection, notifying client
(containing URL) into TCP connection
socket. Message indicates that client
wants object 3. HTTP server receives
someDepartment/[Link]
request message, forms
response message
containing requested
object, and sends
time message into its socket

Application Layer 2-31

 Non-persistent HTTP (cont.)
4. HTTP server closes TCP
connection.
5. HTTP client receives
response message
containing html file,
displays html. Parsing html
file, finds 10 referenced
jpeg objects
time
6. Steps 1-5 repeated for
each of 10 jpeg objects

Application Layer 2-32

Non-persistent HTTP: response
time
RTT (definition): time for a small
packet to travel from client to
server and back
HTTP response time:
 one RTT to initiate TCP
connection initiate TCP
 one RTT for HTTP request and connection
first few bytes of HTTP RTT
response to return
 file transmission time request
file
 non-persistent HTTP response
time to
time = RTT transmit
2RTT+ file transmission file
time file
received
Note : RTT includes packet-
propagation delays, packet-
queuing delays in intermediate time time
routers and switches, and
packet-processing delays.

Application Layer 2-33

Persistent HTTP

non-persistent HTTP persistent HTTP:

issues:  server leaves
 requires 2 RTTs per connection open after
sending response
object  subsequent HTTP
 OS overhead for each messages between
TCP connection same client/server sent
 browsers often open over open connection
parallel TCP  client sends requests
connections to fetch as soon as it
referenced objects encounters a
referenced object
 as little as one RTT for
all the referenced
objects

Application Layer 2-34

 HTTP request message
 two types of HTTP messages: request,
response
 HTTP request message:
 ASCII (human-readable format) carriage return character
line-feed character
request line
(GET, POST, GET /[Link] HTTP/1.1\r\n
HEAD commands) Host: [Link]\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
headerAccept-Language: en-us,en;q=0.5\r\n
linesAccept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
carriage return, Keep-Alive: 115\r\n
line feed at start Connection: keep-alive\r\n
\r\n
of line indicates
end of header lines
Application Layer 2-35
HTTP request message: general
format
method sp URL sp version cr lf request
line
header field name value cr lf
header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body

Application Layer 2-36

Continued…

• The request line has three fields: The method field, the URL field, and
the HTTP version field.
• The method field can take on several different values, including GET,
POST, HEAD, PUT, and DELETE.
The great majority of HTTP request messages use the GET method.
• The GET method is used when the browser requests an object, with
the requested object identified in the URL field.

Example, the browser is requesting the object

/somedir/[Link].

Application Layer 2-37

GET Method
After the header lines (and the additional carriage return and line feed) there
is an “entity body.”

The entity body is empty with the GET method, but is used with the POST
method.

HTML forms often use the GET method and include the inputted data (in the
form fields) in the requested URL.

Example: If a form uses the GET method, has two fields, and the inputs to
the two fields are monkeys and bananas, then the URL will have the
structure
[Link]/animalsearch?monkeys&bananas.

Application Layer 2-38

POST ,HEAD, PUT & DELETE methods
POST method is used when the user fills out a form—for example, when
a user provides search words to a search engine. With a POST message,
the user is still requesting a Web page from the server, but the specific
contents of the Web page depend on what the user entered into the form
fields.
If the value of the method field is POST, then the entity body contains
what the user entered into the form fields.
HEAD method is similar to the GET method. When a server receives a
request with the HEAD method, it responds with an HTTP message but it
leaves out the requested object.
PUT method is often used in conjunction with Web publishing tools. It
allows a user to upload an object to a specific path (directory) on a
specific Web server. The PUT method is also used by applications that
need to upload objects to Web servers.
DELETE method allows a user, or an application, to delete an
object on a Web server.

Application Layer 2-39

Uploading form input
POST method:
 web page often
includes form input
 input is uploaded to
server in entity body

URL method:
 uses GET method
 input is uploaded in
URL field of request
line:
[Link]/animalsearch?monkeys&banana

Application Layer 2-40

Method
types
HTTP/1.0: HTTP/1.1:
 GET  GET, POST, HEAD
 POST  PUT
 HEAD  uploads file in
 asks server to entity body to
leave requested path specified in
object out of URL field
response  DELETE
 deletes file
specified in the
URL field

Application Layer 2-41

Examples of HTTP commands

GET /users (fetches a list of users)

POST/users(creates a new user)

PUT/users/1 (updates user with ID 1)

DELETE/users/1 (deletes user with ID 1)

HEAD/users (checks metadata without retrieving users)

Application Layer 2-42

General format of an HTTP
response message

Application Layer 2-43

 HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
lines Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\
r\n
\r\n
data, e.g., data data data data data ...
requested
HTML file(entity body)
Application Layer 2-44
HTTP response status codes
 status code appears in 1st line in server-to-client response message.
 some sample codes:

200 OK
 request succeeded, requested object later in this msg
301 Moved Permanently
 requested object moved, new location specified later in
this msg (Location:)
400 Bad Request
 request msg not understood by server
404 Not Found
 requested document not found on this server
505 HTTP Version Not Supported
Application Layer 2-45
Trying out HTTP (client side) for
yourself
1. Telnet to your favorite Web server:

telnet [Link] 80 opens TCP connection to port 80 (default HTTP

server port) at [Link]. anything typed in
sent to port 80 at [Link]. Response
message that includes the base HTML file of
Professor Ross’s homepage.

2. type in a GET HTTP request:

By typing this in (hit carriage return

GET /~ross/
twice), you send this minimal (but
HTTP/1.1
complete) GET request to HTTP
Host: [Link]
server
3. If u want to see the HTTP message lines and not receive the object itself, replace GET with HEAD.

L
User-server interaction:
cookies
Web sites want to identify users,
either because the server example:
wishes to restrict user access  Susan always access
or because it wants to serve Internet from PC
content as a function of the 
user identity. For these visits specific e-
purposes, HTTP uses cookies. commerce site for
four components: first time
1) cookie header line of HTTP
 when initial HTTP
response message requests arrives at
2) cookie header line in next site, site creates:
HTTP request message  unique ID
3) cookie file kept on user’s  entry in backend
host & managed by user’s database for ID
browser
4) back-end database at Web
site
Application Layer 2-47
 Cookies: keeping “state” (cont.)
client server

ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response
1678 for user create backend
ebay 8734
set-cookie: 1678 entry database
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action

one week later:

access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
usual http response msg action
Application Layer 2-48
Cookies (continued)
aside
what cookies can cookies and privacy:
be used for:  cookies permit sites to
 authorization learn a lot about you
 shopping carts  you may supply name
 recommendations and e-mail to sites
 user session state
(Web e-mail)

how to keep “state”:

 protocol endpoints: maintain
state at sender/receiver over
multiple transactions
 cookies: http messages carry
state
Application Layer 2-49
 Web caches (proxy server)
goal: satisfy client request without involving origin server.
Is a network entity that satisfies HTTP requests on behalf of an origin Web server.

 user sets browser: Web

proxy
accesses via cache HT
TP u est
req server req
 browser sends all HTTP HT
client TP
ues
t H TTP
o n se
res p origin
requests to cache pon P res
se T server
 object in cache: cache HT
t
ues
returns object req e
TT P o ns
 else cache requests p
H res
object from origin T TP
H
server, then returns
object to client client origin
server

Application Layer 2-50

More about Web caching
 cache acts as why Web caching?
both client and  reduce response time
server for client request
 server for original  reduce traffic on an
requesting client
 client to origin server institution’s access
link
 typically cache is  Internet dense with
installed by ISP caches: enables
(university, “poor” content
company, providers to
residential ISP) effectively deliver
content (so too does
P2P file sharing)
Application Layer 2-51
Caching example:
assumptions:
 avg object size: 100K bits
 avg request rate from browsers
to origin servers:15/sec origin
 avg data rate to browsers: 1.50 servers
Mbps public
 RTT from institutional router to Internet
any origin server: 2 sec(internet
delay)
 access link rate: 1.54 Mbps.
 Traffic intensity at LAN=(15 requests/sec) 1.54 Mbps
. (1Mbits/request)/(100 Mbps) = 0.15 access link
 Traffic intensity at LINK=15 requests/sec)
. (1 Mbits/request)/(15 Mbps) = 1 institutional
network
consequences: 1 Gbps LAN
 LAN utilization: 15%
 access link utilization = 99%
 total delay = Internet delay +
access delay + LAN delay
= 2 sec + minutes + usecs
Application Layer 2-52
 Caching example: fatter
access link
assumptions:
 avg object size: 100K bits origin
 avg request rate from servers
browsers to origin public
servers:15/sec Internet
 avg data rate to browsers:
1.50 Mbps
 RTT from institutional router to
any origin server: 2 sec154 1.54 Mbps
154 Mbps
access link rate: 1.54 Mbps access link

Mbps
institutional
consequences: network
 LAN utilization: 15% 9.9% 1 Gbps LAN
 access link utilization = 99%
 total delay = Internet delay +
access delay + LAN delay
msecs
= 2 sec + minutes + usecs
Cost: increased access link speed (not cheap!)
Application Layer 2-53
 Caching example: install local
cache
assumptions:
 avg object size: 100K bits origin
 avg request rate from servers
browsers to origin public
servers:15/sec Internet
 avg data rate to browsers:
1.50 Mbps
 RTT from institutional router to
any origin server: 2 sec 1.54 Mbps
 access link rate: 1.54 Mbps access link
institutional
consequences: network
 ?
LAN utilization: 15% 1 Gbps LAN
 ? utilization = 100%
access link local web
 Howdelay
total to compute link +
= Internet delay cache
utilization,
access delay + LAN delay?
delay
= 2 sec + minutes + usecs
Cost: web cache (cheap!)
Application Layer 2-54
Caching example: install local
cache
Calculating access link
utilization, delay with cache:
 suppose cache hit rate is 0.4 origin
 40% requests satisfied at cache, 60% servers
requests satisfied at origin public
Internet

 access link utilization:

 60% of requests use access link
 data rate to browsers over access 1.54 Mbps
link = 0.6*1.50 Mbps = .9 Mbps access link
 utilization = 0.9/1.54 = .58
institutional
 total delay network
 = 0.6 * (delay from origin servers) +0.4 * (delay 1 Gbps LAN
when satisfied at cache)
 = 0.6 (2.01) + 0.4 (~msecs)
 = ~ 1.2 secs
local web
 less than with 154 Mbps link (and cheaper too!) cache

Application Layer 2-55

Conditional GET
client server
 Goal: don’t send
object if cache has up-
to-date cached HTTP request msg
object
version If-modified-since: <date>
not
 no object transmission
modified
delay HTTP response
 lower link utilization before
HTTP/1.0
304 Not Modified <date>
 cache: specify date of
cached copy in HTTP
request
If-modified-since:
<date> HTTP request msg
If-modified-since: <date> object
 server: response modified
contains no object if after
HTTP response
cached copy is up-to- HTTP/1.0 200 OK <date>
date: <data>
HTTP/1.0 304 Not
Modified Application Layer 2-56
Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 socket
applications programming
 app architectures with UDP and TCP
 app
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS
Application Layer 2-57
FTP: the file transfer protocol
file transfer
FTP FTP FTP
user client server
interface
user
at host remote file
local file system
system

 User interacts with FTP through an FTP user agent.

 User first provides the hostname of the remote host, causing the FTP client
process in the local host to establish a TCP connection with the FTP server
process in the remote host.
 Transfer file to/from remote host
 client/server model
 client: side that initiates transfer (either to/from remote)
 server: remote host
 ftp: RFC 959
 ftp server: port 21

Application Layer 2-58

FTP: separate control, data
connections
 FTP client initiates a control TCP TCP control connection,
connection with FTP server(Remote server port 21
Host) at port 21,
 Client browses remote directory, sends
TCP data connection,
commands over control connection. FTP server port 20 FTP
 Control connection is used for sending client server
control information between the two
hosts—information such as user
identification, password, commands to  Server opens another TCP data
change remote directory, and connection to transfer another file
commands to “put” and “get” files.  control connection: “out of band”.
 When server receives file transfer  HTTP : In-band.
command, server opens 2nd TCP data  SMTP : In-band.
connection (for file) to client  FTP server maintains “state”:
 After transferring one file, server closes current directory, earlier
data connection authentication

Application Layer 2-59

FTP commands, responses
sample commands: sample return codes
 sent as ASCII text  status code and
over control channel phrase (as in HTTP)
 USER username  331 Username OK,
 PASS password password required
 125 data
 LIST return list of
file in current connection already
directory open; transfer
starting
 RETR filename  425 Can’t open
retrieves (gets) file data connection
 STOR filename  452 Error writing
stores (puts) file onto file
remote host

Application Layer 2-60

Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 socket
applications programming
 app architectures with UDP and TCP
 app
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS
Application Layer 2-61
Electronic mail outgoing
message queue
user mailbox
 It is an asynchronous type of user
communication. agent
 Three major components:
 user agents mail user
 mail servers server agent
 simple mail transfer protocol: SMTP
SMTP mail user
User Agent server agent
 “mail reader”
SMTP
 composing, editing, reading mail
messages SMTP user
 e.g., Microsoft Outlook, Apple mail, agent
mail
Thunderbird, iPhone mail client server
 Outgoing, incoming messages user
stored on server agent
user
agent

Application Layer 2-62

Electronic mail: mail servers
mail servers: user
agent
 mailbox contains
incoming messages for mail user
user server agent
 message queue of SMTP mail user
outgoing (to be sent) server agent
mail messages
SMTP
 SMTP protocol between
mail servers to send SMTP user
email messages mail
agent
 client: sending mail server
user
server agent
 “server”: receiving user
mail server agent

Application Layer 2-63

Electronic Mail: SMTP [RFC
2821]
 uses TCP to reliably transfer email message
from client to server, port 25
 direct transfer: sending server to receiving
server
 three phases of transfer
 handshaking (greeting)
 transfer of messages
 closure
 command/response interaction (like HTTP,
FTP)
 commands: ASCII text
 response: status code and phrase
 messages must be in 7-bit ASCI
Application Layer 2-64
Scenario: Alice sends message
to Bob
1) Alice uses UA to 4) SMTP client sends
compose message “to” Alice’s message over
bob@[Link] the TCP connection
2) Alice’s UA sends 5) Bob’s mail server
message to her mail places the message in
server; message placed Bob’s mailbox
in message queue 6) Bob invokes his user
3) client side of SMTP agent to read message
opens TCP connection
with Bob’s mail server

1 user mail user

mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server
Application Layer 2-65
SMTP transferring a message from a sending mail server to a
receiving mail server.
• First, the client SMTP (running on the sending mail server host) has TCP,
establish a connection to port 25 at the server SMTP (running on the receiving
mail server host).
• If the server is down, the client tries again later.
• Once this connection is established, the server and client perform some
application-layer handshaking—just as humans often introduce themselves
before transferring information from one to another.
• During this SMTP handshaking phase, the SMTP client indicates the e-mail
address of the sender (the person who generated the message) and the e-mail
address of the recipient.
• Once the SMTP client and server have introduced themselves to each other,
the client sends the message.

Application Layer 2-66

 Sample SMTP interaction
: 220 [Link] //server is ready to proceed with the next command
: HELO [Link]
: 250 Hello [Link], pleased to meet you
: MAIL FROM: <alice@[Link]>
: 250 alice@[Link]... Sender ok //indicates a successful SMTP command or action
: RCPT TO: <bob@[Link]>
: 250 bob@[Link] ... Recipient ok
: DATA
: 354 Enter mail, end with "." on a line by itself
: Do you like ketchup?
: How about pickles?
:.
: 250 Message accepted for delivery
: QUIT
: 221 [Link] closing connection

Application Layer 2-67

Try SMTP interaction for
yourself:
 telnet servername 25
 see 220 reply from server
 enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands

above lets you send email without using email

client (reader)

Application Layer 2-68

SMTP: final words
 SMTP uses persistent comparison with HTTP:
connections  HTTP: pull(TCP connection is
 SMTP requires message initiated by the machine that
(header & body) to be in wants to receive the file).
7-bit ASCII  SMTP: push(machine that wants
 SMTP server uses to send the file).
[Link] to determine
end of message (Carriage  SMTP: requires each message,
Return Line Feed). including the body of each
 This restriction made message, to be in 7-bit ASCII
sense in the early 1980s format.
when trans-  Both have ASCII
mission capacity was command/response interaction,
scarce and no one was e- status codes.
mailing large attachments
or large image, audio, or  HTTP: each object encapsulated
video files. in its own response msg.
 SMTP: multiple objects sent in
Application Layer 2-69
multipart msg.
Mail message format
SMTP: protocol for
exchanging email
msgs header
blank
RFC 822: standard for
line
text message
format:
 header lines, e.g.,
body
 To:
 From:
 Subject:
HTTP commands are
different from SMTP
MAIL FROM, RCPT TO:
commands!
 Body: the “message”
 ASCII characters only
Application Layer 2-70
Need of Mail access
protocols
• Any user reads e-mail with a client that executes on the user’s end
system.

• By executing a mail client on a local PC, users enjoy a rich set of features,
including the ability to view multimedia messages and attachments.

• Given that Bob (the recipient) executes his UA on his local PC, it is natural
to consider placing a mail server on his local PC as well.

• Then Alice’s mail server would dialogue directly with Bob’s PC.

• However there is a problem with this approach !!

• Note that a mail server manages mailboxes and runs the client and server
sides of SMTP. If Bob’s mail server were to reside on his local PC, then
Bob’s PC would have to remain always on, and connected to the Internet.

• Solution: A typical user runs a UA on the local PC but accesses its

mailbox stored on an always-on shared mail server.

Application Layer 2-71

Mail access protocols
user
mail user
SMTP SMTP access
agent agent
protocol
(e.g., POP,
IMAP)

sender’s mail receiver’s mail

server server
 Once SMTP delivers the message from Alice’s mail server to Bob’s mail
server, the message is placed in Bob’s mailbox.
 mail access uses a client-server architecture.
 mail access protocol: retrieval from server
 POP: Post Office Protocol [RFC 1939]: authorization, download
 IMAP: Internet Mail Access Protocol [RFC 1730]: more
features, including manipulation of stored msgs on server
 HTTP: gmail, Hotmail, Yahoo! Mail, etc.

Application Layer 2-72

How does a recipient like Bob, running a user agent on his local PC,
obtain his messages, which are sitting in a mail server within Bob’s
ISP?

Solution: Bob’s UA can’t use SMTP to obtain the messages

because obtaining the messages is a pull operation, whereas SMTP
is a push protocol.

• Introduce a special mail access protocol that transfers messages

from Bob’s mail server to his local PC.

•There are currently a number of popular mail access protocols,

including Post Office Protocol—Version 3 (POP3), Internet Mail
Access Protocol (IMAP), and HTTP.

Application Layer 2-73

POP3
 Is an extremely simple mail access
protocol. It is defined in [RFC 1939],
which is short and quite readable.
Because the protocol is so simple, its
functionality is rather limited.
 POP3 begins when the user agent (the
client) opens a TCP connection to the
mail server (the server) on port 110.

Application Layer 2-74

Three phases of POP3
 With the TCP connection established, POP3 progresses
through three phases:
 Authorization: UA sends a username and a password
(in the clear) to authenticate the user.
 Transaction: UA retrieves messages; also during this
phase, the user agent can mark messages for deletion,
remove deletion marks, and obtain mail statistics
 Update: occurs after the client has issued the quit
command, ending the POP3 session; at this time, the
mail server deletes the messages that were marked for
deletion.

Application Layer 2-75

POP3 protocol
S: +OK POP3 server ready
C: user bob
authorization phase S: +OK
 Principal client commands: C: pass hungry
 user: declare username S: +OK user successfully logged on

 pass: password C: list

 server responses S: 1 498
 +OK S: 2 912
 -ERR S: .
transaction phase, C: retr 1
client: UA using POP3 can often be
S: <message 1 contents>
configured (by the user) to “download S: .
and delete” or to “download and keep.” C: dele 1
 list: list message numbers C: retr 2
 retr: retrieve message by S: <message 1 contents>
number S: .
 dele: delete C: dele 2
 quit C: quit
S: +OK POP3 server signing off
Application Layer 2-76
download and delete
 POP3 can often be configured (by the user) to
“download and delete” or to “download and keep.”
 In the download-and-delete mode, the user agent will
issue the list, retr, and dele commands.
 A problem with this download-and-delete mode is that
the recipient, Bob, may want to access his mail
messages from multiple machines, for example, his
office PC, his home PC, and his portable computer.
 The download- and-delete mode partitions Bob’s mail
messages over these three machines; in particular, if
Bob first reads a message on his office PC, he will not be
able to reread the message from his portable at home
later in the evening

Application Layer 2-77

download-and- keep mode
 In the download-and- keep mode, the user agent leaves
the messages on the mail server after downloading
them. In this case, Bob can reread messages from
different machines; he can access
a message from work and access it again later in the
week from home.

Application Layer 2-78

POP3 (more) and IMAP
 previous example uses POP3 “download and delete” mode
 Bob cannot re-read e-mail if he changes client(office pc, Home pc &
portable computer)
 POP3 “download-and-keep”: Leaves messages on server, copies of messages
on different clients
 POP3 is stateless across sessions.
 Drawback:
• With POP3 access, once Bob has downloaded his messages to the local
machine, he can create mail folders and move the downloaded messages into
the folders.
• Bob can then delete messages, move messages across folders, and search for
messages (by sender name or subject). But this paradigm—namely, folders
and messages in the local machine—poses a problem for the nomadic user,
who would prefer to maintain a folder hierarchy on a remote server that can
be accessed from any computer.
• This is not possible with POP3—the POP3 protocol does not provide any
means for a user to create remote folders and assign messages to folders.

Application Layer 2-79

IMAP(Internet Mail Access
Protocol)
•Like POP3, IMAP is a mail access protocol.

• It has many more features than POP3, but it is also significantly more
complex. (And thus the client and server side implementations are
significantly more complex.)

•keeps all messages in one place: at server allows user to organize messages
in folders.

•keeps user state across sessions , names of folders and mappings between
message IDs and folder names.

Application Layer 2-80

Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 socket
applications programming
 app architectures with UDP and TCP
 app
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS
Application Layer 2-81
DNS: domain name system
people: many identifiers: Domain Name System:
 SSN, name,  distributed database
passport # implemented in hierarchy
Internet hosts, routers: of many name servers
 IP address (32 bit) -  application-layer protocol:
used for addressing hosts, name servers
datagrams communicate to resolve
 “name”, e.g., names (address/name
[Link] - translation)
used by humans  note: core Internet
function, implemented as
Q: how to map between application-layer protocol
IP address and name,  complexity at network’s
and vice versa ?
“edge”

Application Layer 2-82

Services provided DNS :
 Host aliasing. A host with a complicated hostname can have one or
more alias names.
example: [Link]- [Link]( canonical hostname.)
[Link] and [Link]. (Alias host-names)
 Mail server aliasing: it is highly desirable that e-mail addresses be
mnemonic.
 Example: if Bob has an account with Hotmail, his e-mail address ,
bob@[Link]. However, the host name of the Hotmail mail
server is, [Link].
 Load distribution. Is also used to perform load distribution among
replicated servers.
 Examples: Web servers, Busy sites, such as [Link], are replicated
over multiple servers. with each server running on a different end
system and each having a different IP address.
 IP addresses is thus associated with one canonical hostname.
 The DNS database contains this set of IP addresses. When clients
make a DNS query for a name mapped to a set of addresses, the server
responds with the entire set of IP addresses, but rotates the ordering of
the addresses within each reply.

Application Layer 2-83

DNS: services, structure
DNS services why not centralize
 hostname to IP DNS?
address translation  single point of failure
 host aliasing  traffic volume
 canonical, alias  distant centralized
names database(Delays)
 mail server aliasing  Use Congested and slow links
 load distribution  maintenance
 replicated Web A: doesn’t scale!
servers: many IP
addresses
correspond to one
name

Application Layer 2-84

DNS: a distributed, hierarchical
database
Root DNS Servers

… …

com DNS servers org DNS servers edu DNS servers

[Link] [Link] [Link]

[Link] [Link]
DNS servers DNS serversDNS servers
DNS servers DNS servers

client wants IP for [Link]; 1st approx:

 client queries root server to find com DNS server
 client queries .com DNS server to get [Link]
DNS server
 client queries [Link] DNS server to get IP
address for [Link]

Application Layer 2-85

 DNS: root name servers
 contacted by local name server that can not
resolve name
 root name server:
 contacts authoritative name server if name mapping
not known
 gets mapping
 returns mapping
c. Cogent, Herndon, to local
VA (5 other sites) name server
k. RIPE London (17 other sites)
d. U Maryland College Park, MD
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)

m. WIDE Tokyo
e. NASA Mt View, CA (5 other sites)
f. Internet Software C.
Palo Alto, CA (and 48 other sites)

a. Verisign, Los Angeles CA

13 root name “servers”
(5 other sites) worldwide
b. USC-ISI Marina del Rey, CA
l. ICANN Los Angeles, CA 247 (till 2011)
(41 other sites)
g. US DoD Columbus,
OH (5 other sites)

Application Layer 2-86

TLD, authoritative servers
top-level domain (TLD) servers:
 responsible for com, org, net, edu, aero, jobs,
museums, and all top-level country domains,
e.g.: uk, fr, ca, jp
 Network Solutions maintains servers for .com TLD
 erisign Global Registry Services for .com.
 Educause for .edu TLD
authoritative DNS servers:
 organization’s own DNS server(s), providing
authoritative hostname to IP mappings for
organization’s named hosts to the public.
 can be maintained by organization or service
provider

Application Layer 2-87

Local DNS name server
 does not strictly belong to hierarchy
 each ISP (residential ISP, company,
university) has one
 also called “default name server”
 when host makes DNS query, query is
sent to its local DNS server
 has local cache of recent name-to-address
translation pairs (but may be out of date!)
 acts as proxy, forwards query into hierarchy

Application Layer 2-88

 DNS name
resolution root DNS server

example 2
 Host at [Link] wants IP 3
address for [Link] TLD DNS server
4
The query sent from [Link] to
[Link] is a recursive 5
query, since the query asks
[Link] to obtain the local DNS server
mapping on its behalf. But the [Link]
subsequent three queries are 7 6
1 8
iterative since all of the replies
are directly returned to
[Link]. authoritative DNS server
 contacted server replies with [Link]
name of server to contact. requesting host
 “I don’t know this name, but ask
[Link]
this server”
[Link]

Application Layer 2-89

DNS name root DNS server
resolution example
2 3
recursive query: 7
6
 puts burden of name
resolution on TLD DNS
server
contacted name
server local DNS server
 heavy load at upper [Link] 5 4
levels of hierarchy? 1 8

authoritative DNS server

[Link]
requesting host
[Link]

[Link]

Application Layer 2-90

DNS: caching, updating
records
 once (any) name server learns mapping, it
caches mapping
 cache entries timeout (disappear) after some
time (TTL)
 TLD servers typically cached in local name
servers
• thus root name servers not often visited
 cached entries may be out-of-date (best
effort name-to-address translation!)
 if name host changes IP address, may not be
known Internet-wide until all TTLs expire
 update/notify mechanisms proposed IETF
standard
 RFC 2136
Application Layer 2-91
DNS records
DNS: distributed db storing resource records (RR)
RR format: (name, value, type, ttl)

type=A type=CNAME
 name is hostname  name is alias name for some
 value is IP address “canonical” (the real) name
 [Link] is really
type=NS
 name is domain (e.g., [Link]
[Link])  value is canonical name
 value is hostname of
authoritative name type=MX
server for this domain
 value is name of mailserver
associated with name

Application Layer 2-92

DNS protocol, messages
 query and reply messages, both with same message format

2 bytes 2 bytes

msg header identification flags

 identification: 16 bit # # questions # answer RRs

for query, reply to
# authority RRs # additional RRs
query uses same #
 flags: questions (variable # of questions)
 query or reply(0 or
1) answers (variable # of RRs)
 recursion desired
 recursion available authority (variable # of RRs)
 reply is authoritative
additional info (variable # of RRs)

Application Layer 2-93

DNS Message Fields
• The first 12 bytes is the header section, which has a number of fields.
• The first field is a 16-bit number that identifies the query. This identifier is
copied into the reply message to a query, allowing the client to match
received replies with sent queries.
• There are a number of flags in the flag field. A 1-bit query/reply flag
indicates whether the message is a query (0) or a reply (1).
• A 1-bit authoritative flag is set in a reply message when a DNS server is an
authoritative server for a queried name.
• A 1-bit recursion-desired flag is set when a client (host or DNS server)
desires that the DNS server perform recursion when it doesn’t have the
record.
• A 1-bit recursion- available field is set in a reply if the DNS server supports
recursion.

Application Layer 2-94

DNS protocol, messages
Answer section contains the resource records for the name that was originally queried. Recall
that in each resource record there is the Type (for example, A, NS, CNAME, and MX), the
Value, and the TTL. A reply can return multiple RRs in the answer, since a hostname can have
multiple IP addresses 2 bytes 2 bytes

name, type fields

for a query
RRs in
response
to query
records for
authoritative servers
additional “helpful”
info that may be used
Application Layer 2-95
Inserting records into DNS
 example: new startup “Network Utopia”
 register name [Link] at DNS
registrar (e.g., Network Solutions)
 provide names, IP addresses of authoritative
name server (primary and secondary)
 registrar inserts two RRs into .com TLD server:
([Link], [Link], NS)
([Link], [Link], A)
 create authoritative server type A record for
[Link]; type MX record
for [Link]

Application Layer 2-96

Attacking DNS
DDoS attacks Redirect attacks
 Bombard root  Man-in-middle
servers with traffic  Intercept queries
 Not successful to  DNS poisoning
date  Send bogus relies to
 Traffic Filtering DNS server, which
 Local DNS servers caches
cache IPs of TLD Exploit DNS for DDoS
servers, allowing
 Send queries with
root server bypass
 Bombard TLD spoofed source
servers address: target IP
 Potentially more  Requires
dangerous amplification
Application Layer 2-97
Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 video streaming
applications and content
 app architectures distribution
 app networks
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS
Application Layer 2-98
Pure P2P architecture
 no always-on server
 arbitrary end systems
directly communicate
 peers are
intermittently
connected and change
IP addresses

examples:
 file distribution
(BitTorrent)
 Streaming (KanKan)
 VoIP (Skype)

Application Layer 2-99

File distribution: client-server vs
P2P
Question: how much time to distribute file (size F) from one
server to N peers?
 peer upload/download capacity is limited resource

us: server upload

capacity

u1 di: peer i download

file, size F us d1 u2 capacity
d2
server
di
uN network (with abundant
bandwidth) ui
dN
ui: peer i upload
capacity

Application Layer 2-100

File distribution time: client-server
 server transmission: must
sequentially send F
(upload) N file copies: us
 time to send one copy: F/us di
 time to send N copies: NF/us network
ui
 client: each client must
download file copy
 dmin = min client download
rate
 min client download time:
F/dmin time to distribute F
to N clients using
Dc-s > max{NF/us,,F/dmin}
client-server approach

increases linearly in N
Application Layer 2-101
File distribution time: P2P
 server transmission:
must upload at least F
us
one copy
di
  time each
client: to send one copy:
client must network
F/us
download file copy ui
 min client download time:
F/dmin
 clients: as aggregate must download NF
bits
 max upload rate (limting max download rate) is
us + ui
time to distribute F
DP2P
to N clients using > max{F/us,,F/dmin,,NF/(us + ui)}
P2P approach

increases linearly in N …
… but so does this, as each peer brings service capacity
Application Layer 2-102
 Client-server vs. P2P: example
client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us

3.5
P2P
Minimum Distribution Time

3
Client-Server
2.5

1.5

0.5

0
0 5 10 15 20 25 30 35

N
Application Layer 2-103
 P2P file distribution:
BitTorrent
 file divided into 256Kb chunks
 peers in torrent send/receive file chunks

tracker: tracks peers torrent: group of

participating in torrent peers exchanging
chunks of a file

Alice arrives …
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent

Application Layer 2-104

P2P file distribution: BitTorrent
 peer joining torrent:
 has no chunks, but will
accumulate them over
time from other peers
 registers with tracker to
get list of peers,
connects to subset of
peers (“neighbors”)
 while downloading, peer uploads chunks to other
peers
 peer may change peers with whom it exchanges
chunks
 churn: peers may come and go
 once peer has entire file, it may (selfishly) leave or
(altruistically) remain in torrent Application Layer 2-105
BitTorrent: requesting, sending file
chunks
requesting chunks: sending chunks: tit-for-tat
 at any given time,  Alice sends chunks to those
different peers have four peers currently sending
her chunks at highest rate
different subsets of  other peers are choked by Alice
file chunks (do not receive chunks from her)
 periodically, Alice asks  re-evaluate top 4 every10 secs
each peer for list of  every 30 secs: randomly
chunks that they have select another peer, starts
sending chunks
 Alice requests missing  “optimistically unchoke” this
chunks from peers, peer
rarest first  newly chosen peer may join top
4

Application Layer 2-106

 BitTorrent: tit-for-tat
(1) Alice “optimistically unchokes” Bob
(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
(3) Bob becomes one of Alice’s top-four providers

higher upload rate: find

better trading partners,
get file faster !
Application Layer 2-107
Multimedia Network Applications
Multimedia applications can be classified into three broad
categories:
(i)streaming stored audio/video,
(ii)conversational voice/video-over-IP, and
(iii)streaming live audio/video.

Application Layer 2-108

Video Streaming
 Client typically begins video playout within a few seconds
after it begins receiving the video from the server. This
means that the client will be playing out from one location
in the video while at the same time receiving later parts of
the video from the server. This technique, known as
streaming, avoids having to download the entire video file
(and incurring a potentially long delay) before playout
begins.
 stream video traffic: major consumer of Internet
bandwidth
• Netflix, YouTube, Amazon Prime: 80% of residential ISP
traffic (2020)
 challenge: scale - how to reach ~1B users?

 challenge: heterogeneity
 different users have different capabilities (e.g., wired versus mobile;
bandwidth rich versus bandwidth poor)
 solution: distributed, application-level infrastructure
Application Layer: 2-109
Three key distinguishing features:
1. Streaming
2. Interactivity. Because the media is prerecorded, the user may pause,
reposition forward, reposition backward, fast-forward, and so on through the
video content.
3. Continuous playout. Once playout of the video begins, it should proceed
according to the original timing of the recording. Therefore, data must be
received from the server in time for its playout at the client; otherwise, users
experience video frame freezing .
• Note :For many streaming video applications, prerecorded video is stored on,
and streamed from, a CDN rather than from a single data center. There are
also many P2P video streaming applications for which the video is stored on
users’ hosts (peers), with different chunks of video arriving from different
peers that may spread around the globe.

Application Layer 2-110

Conversational Voice- and Video-over-IP
• It is often referred to as Internet telephony, since, from the user’s perspective, it
is similar to the traditional circuit- switched telephone service. It is also commonly
called Voice-over-IP (VoIP). Conversational video is similar, except that it includes
the video of the participants as well as their voices.
• Two of the axes along which application requirements are classified are—timing
considerations and tolerance of data loss—are particularly important for
conversational voice and video applications.
• Delay-sensitive: should be less than a few hundred milliseconds. For voice, delays
smaller than 150 milliseconds are not perceived by a human listener, delays
between 150 and 400 milliseconds can be acceptable, and delays exceeding 400
milliseconds can result in frustrating.
• Loss-tolerant— occasional loss only causes occasional glitches in audio/video
playback, and these losses can often be partially or fully concealed.

Application Layer 2-111

Streaming Live Audio and Video
• It is similar to traditional broadcast radio and television, except that
transmission takes place over the Internet.
• These applications allow a user to receive a live radio or television transmission
—such as a live sporting event or an ongoing news event—transmitted from
any corner of the world.
• Live, broadcast-like applications often have many users who receive the same
audio/video program at the same time. Although the distribution of live
audio/video to many receivers can be efficiently accomplished using the IP
multicasting techniques

Application Layer 2-112

Multimedia: video
 video: sequence of images displayed spatial coding example: instead of

at constant rate sending N values of same color

(all purple), send only two values:

• e.g., 24 images/sec color value (purple) and number

of repeated values (N)

 digital image: array of pixels ……………………..

……………….…….
• each pixel represented by bits
 coding: use redundancy within and
between images to decrease # bits
used to encode image
• spatial (within image) frame i

• temporal (from one image to next)

temporal coding example:
instead of sending
complete frame at i+1,
send only differences from
frame i frame i+1

Application Layer: 2-113

Multimedia: video spatial coding example: instead of
sending N values of same color
(all purple), send only two values:
color value (purple) and number

 CBR: (constant bit rate): video of repeated values (N)

encoding rate fixed ……………………..

……………….…….
 VBR: (variable bit rate): video
encoding rate changes as
amount of spatial, temporal
coding changes
 examples: frame i

• MPEG 1 (CD-ROM) 1.5 Mbps

• MPEG2 (DVD) 3-6 Mbps
temporal coding example:
• MPEG4 (often used in instead of sending
complete frame at i+1,

Internet, 64Kbps – 12 Mbps) send only differences from

frame i frame i+1

Application Layer: 2-114

Streaming stored video

simple scenario:

Internet
video server
client
(stored video)

Main challenges:
server-to-client bandwidth will vary over time,
with changing network congestion levels (in
house, access network, network core, video
server)
packet loss, delay due to congestion will delay
playout, or result in poor video quality Application Layer: 2-115
Streaming stored video
Cumulative data

2. video
sent
1. video 3. video received, played out at
recorded client
(e.g., 30 (30 frames/sec) time
network delay
frames/se (fixed in this
c) example)
streaming: at this time, client playing out
early part of video, while server still sending
later part of video
Application Layer: 2-116
Streaming stored video: challenges
 continuous playout constraint: during client
video playout, playout timing must match
original timing
• … but network delays are variable (jitter), so will
need client-side buffer to match continuous playout
constraint
 other challenges:
• client interactivity: pause, fast-forward, rewind,
jump through video
• video packets may be lost, retransmitted
Application Layer: 2-117
Streaming stored video: playout
buffering
constant bit
rate video client video constant bit
Cumulative data

transmission reception rate video

playout at client
variable

buffered
network

video
delay

client playout time

delay

 client-side buffering and playout delay: compensate for network-

added delay, delay jitter
Application Layer: 2-118
Streaming multimedia: DASH
Dynamic, Adaptive
Streaming over
HTTP
server:
 divides video file into multiple chunks ...
 each chunk encoded at multiple different rates ...
 different rate encodings stored in different files
?
 files replicated in various CDN nodes
 ...
manifest file: provides URLs for different chunks client

client:
 periodically estimates server-to-client bandwidth
 consulting manifest, requests one chunk at a time
• chooses maximum coding rate sustainable given current bandwidth
• can choose different coding rates at different points in time (depending
on available bandwidth at time), and from different servers
Application Layer: 2-119
Streaming multimedia: DASH

 “intelligence” at client: client

determines ...
• when to request chunk (so that buffer ...
starvation, or overflow does not occur) ?
• what encoding rate to request (higher ... client
quality when more bandwidth
available)
• where to request chunk (can request
from URL server that is “close” to
client or has high available
bandwidth)

Streaming video = encoding + DASH + playout buffering

Application Layer: 2-120
Content distribution networks
(CDNs)

challenge: how to stream content (selected from millions of

videos) to hundreds of thousands of simultaneous users?
 option 1: single, large “mega-
server”
• single point of failure
• point of network congestion
• long (and possibly congested)
path to distant clients

….quite simply: this solution doesn’t scale

Application Layer: 2-121
Content distribution networks
(CDNs)

challenge: how to stream content (selected from millions of

videos) to hundreds of thousands of simultaneous users?
 option 2: store/serve multiple copies of videos at multiple
geographically distributed sites (CDN)
• enter deep: push CDN servers deep into many access networks
• close to users
• Akamai: 240,000 servers deployed
in > 120 countries (2015)
• bring home: smaller number (10’s) of
larger clusters in POPs near access nets
• used by Limelight

Application Layer: 2-122

Content distribution networks (CDNs)
 CDN: stores copies of content (e.g. MADMEN) at CDN nodes
 subscriber requests content, service provider
returns manifest
• using manifest, client retrieves content at highest supportable rate
• may choose different rate or copy if network path congested

… …

…
manifest file
…

where’s Madmen?

… …
Application Layer: 2-123
Content distribution networks (CDNs)

OTT: “over the top”

… …
Internet host-host communication as a service

…
…

OTT challenges: coping with a congested Internet from the “edge”

 what content to place in which CDN node?
 from which CDN node to retrieve content? At which rate?
… …
Application Layer: 2-124
Chapter 2:
summary
our study of network apps now complete!
 application architectures  specific protocols:
 client-server  HTTP
 P2P
 FTP
 application service
requirements:  SMTP, POP, IMAP
 reliability, bandwidth,  DNS
delay
 P2P: BitTorrent, DHT
 Internet transport service
model  video streaming and
 connection-oriented, content distribution
reliable: TCP networks
 unreliable, datagrams: UDP

Application Layer 2-125

Chapter 2: summary
most importantly: learned about protocols!

 typical request/reply important themes:

message exchange:
 client requests info
 control vs. data msgs
or service  in-band, out-of-band
 server responds with  centralized vs.
data, status code decentralized
 message formats:  stateless vs. stateful
 headers: fields giving
info about data
 reliable vs. unreliable msg
 data: info being transfer
communicated  “complexity at network
edge”

Application Layer 2-126