Application Layer: Overview

 P2P applications
 Principles of network  video streaming and content
applications distribution networks
 Web and HTTP  socket programming with
 E-mail, SMTP, IMAP UDP and TCP
 The Domain Name System
DNS

Application Layer: 2-1

 Suppose within your Web browser you click on a link
to obtain a Web page. The IP address for the
associated URL is not cached in your local host, so a
DNS lookup is necessary to obtain the IP address.
Suppose that three DNS servers are visited before your
host receives the IP address from DNS. The first DNS
server visited is the local DNS cache, with an RTT delay
of RTT0 = 3 msecs. The second and third DNS servers
contacted have RTTs of 45 and 22 msecs, respectively.
Initially, let's suppose that the Web page associated
with the link contains exactly one object, consisting of
a small amount of HTML text. Suppose the RTT
between the local host and the Web server containing
the object is RTTHTTP = 26 msecs.

1. Assuming zero transmission time for the HTML object, how much time (in msec) elapses from when
the client clicks on the link until the client receives the object?

The time from when the Web request is made in the browser until the page is displayed in the browser is:
RTT0 + RTT1 + RTT2 + 2*RTTHTTP = 3 + 45 + 22 + 2*26 = 122 msecs. Note that 2 RTT HTTP are needed to
fetch the HTML object - one RTTHTTP to establish the TCP connection, and then one RTTHTTP to perform
the HTTP GET/response over that TCP connection.
Application Layer: 2-2
Now suppose the HTML object references 4 very small objects on the same server. Neglecting
transmission times, how much time (in msec) elapses from when the client clicks on the link
until the base object and all 4 additional objects are received from web server at the client,
assuming non-persistent HTTP and no parallel TCP connections?

The time from when the Web request is made in the browser until the page is
displayed in the browser is: RTT0 + RTT1 + RTT2 + 2*RTTHTTP + 2*4*RTTHTTP = 3 + 45 + 22 +
2*26 + 2*4*26 = 330 msecs. Note that two RTTHTTP delays are needed to fetch the base
HTML object - one RTTHTTP to establish the TCP connection, and one RTTHTTP to send the
HTTP request, and receive the HTTP reply. Then, serially, for each of the 4 embedded
objects, a delay of 2*RTTHTTP is needed - one RTTHTTP to establish the TCP connection and
then one RTTHTTP to perform the HTTP GET/response over that TCP connection.

Application Layer: 2-3

What's the fastest method we've explored: Non-persistent-serial, Non-
persistent-parallel, or Persistent-parallel?

The delay when using persistent parallel connections is faster than

using non-persistent parallel connections, which is faster than using
non-persistent serial connections.

Application Layer: 2-4

  Consider the scenario shown below, with four
different servers connected to four different
clients over four three-hop paths. The four pairs
share a common middle hop with a transmission
capacity of R = 200 Mbps. The four links from the
servers to the shared link have a transmission
capacity of RS = 40 Mbps. Each of the four links
from the shared middle link to a client has a
transmission capacity of RC = 20 Mbps.

What is the maximum achievable end-end throughput (in

Mbps) for each of four client-to-server pairs, assuming that
the middle link is fairly shared (divides its transmission
rate equally)?

The maximum achievable end-end throughput is the

capacity of the link with the minimum capacity, which is 20
Mbps

Application Layer: 2-5

Assuming that the servers are sending at the maximum rate possible,
what are the link utilizations for the server links (RS)?
The server's utilization = Rbottleneck / RS = 20 / 40 = 0.5

Assuming that the servers are sending at the maximum rate possible,
what are the link utilizations for the client links (RC).
The client's utilization = Rbottleneck / RC = 20 / 20 = 1

Application Layer: 2-6

Peer-to-peer (P2P) architecture
 no always-on server mobile network
 arbitrary end systems directly national or global ISP

communicate
 peers request service from other
peers, provide service in return to
other peers local or
regional ISP
• self scalability – new peers bring new
service capacity, and new service demands home network content
 peers are intermittently connected provider
network datacenter
network
and change IP addresses
• complex management
 examples: P2P file sharing (BitTorrent), enterprise
network
streaming (KanKan), VoIP (Skype)
Application Layer: 2-7
File distribution: client-server vs P2P
Q: 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
di: peer i download
file, size F u1 d1 u2 capacity
us d2
server
di
uN network (with abundant
bandwidth) ui
dN
ui: peer i upload
capacity
Introduction: 1-8
 File distribution time: client-server
 server transmission: must sequentially
send (upload) N file copies:
F
• time to send one copy: F/us us

• time to send N copies: NF/us di

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 Introduction: 1-9

File distribution time: P2P
 server transmission: must upload at
least one copy:
F
• time to send one copy: F/us us
 client: each client must download di
network
file copy ui
• min client download time: F/dmin
 clients: as aggregate must download NF bits
• max upload rate (limiting max download rate) is us + Sui

time to distribute F
to N clients using
P2P approach
DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}
increases linearly in N …
… but so does this, as each peer brings service capacity Application Layer: 2-10
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-11
P2P file distribution: BitTorrent
 file divided into 256Kb chunks
 peers in torrent send/receive file chunks
tracker: tracks peers torrent: group of peers
participating in torrent 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-12

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
 once peer has entire file, it may (selfishly) leave or (altruistically) remain
in torrent

Application Layer: 2-13

BitTorrent: requesting, sending file chunks

Requesting chunks: Sending chunks: tit-for-tat

 at any given time, different  Alice sends chunks to those four
peers have different subsets peers currently sending her chunks
of file chunks at highest rate
 periodically, Alice asks each • other peers are choked by Alice (do
not receive chunks from her)
peer for list of chunks that • re-evaluate top 4 every10 secs
they have  every 30 secs: randomly select
 Alice requests missing another peer, starts sending
chunks from peers, rarest chunks
first • “optimistically unchoke” this peer
• newly chosen peer may join top 4
Application Layer: 2-14
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-15

Application layer: overview
 P2P applications
 Principles of network  video streaming and content
applications distribution networks
 Web and HTTP  socket programming with
 E-mail, SMTP, IMAP UDP and TCP
 The Domain Name System
DNS

Application Layer: 2-16

Application layer: overview
 P2P applications
 Principles of network  video streaming and content
applications distribution networks
 Web and HTTP  socket programming with
 E-mail, SMTP, IMAP UDP and TCP
 The Domain Name System
DNS

Application Layer: 2-17

Video Streaming and CDNs: context

 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-18
Multimedia: video spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and
 video: sequence of images number of repeated values (N)

displayed at constant rate ……………………..

……………….…….
• e.g., 24 images/sec
 digital image: array of pixels
• each pixel represented by bits
 coding: use redundancy within and frame i
between images to decrease # bits
used to encode image
• spatial (within image) temporal coding example:
instead of sending
• temporal (from one image to complete frame at i+1,

next) send only differences from

frame i frame i+1

Application Layer: 2-19

Multimedia: video spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and
 CBR: (constant bit rate): video number 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-20

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-21
Streaming stored video
Cumulative data

2. video
sent
1. video 3. video received, played out at client
recorded (30 frames/sec)
(e.g., 30 time
network delay
frames/sec) (fixed in this
example)
streaming: at this time, client playing out
early part of video, while server still sending
later part of video
Application Layer: 2-22
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-23
Streaming stored video: playout buffering

constant bit
Cumulative data rate video client video constant bit
transmission reception rate video
playout at client
variable
network

buffered
video
delay

client playout time

delay

 client-side buffering and playout delay: compensate for

network-added delay, delay jitter
Application Layer: 2-24
 Dynamic, Adaptive
Streaming multimedia:Streaming
DASH 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-25
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-26
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-27
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-28
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-29
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-30
Case study: Netflix
Amazon cloud upload copies of
multiple versions of
video to CDN servers
CDN
server
Netflix registration,
accounting servers
Bob browses
Netflix video CDN
2 Manifest file, server
requested
1 3 returned for
Bob manages specific video
Netflix account
CDN
4 server

DASH server
selected, contacted,
streaming begins
Application Layer: 2-31