Week 2-3
Week 2-3
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
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
provider
peers are intermittently connected network datacenter
network
and change IP addresses
• complex management
examples: P2P file sharing (BitTorrent), enterprise
network
streaming (KanKan), VoIP (Skype)
Application Layer: 2-2
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-3
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 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-5
Client-server vs. P2P: example
client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
3.5
P2P
1.5
0.5
0
0 5 10 15 20 25 30 35
N
Application Layer: 2-6
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
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-13
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-14
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-15
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:
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-17
Streaming multimedia: DASH
“intelligence” at client: client
determines ...
• when to request chunk (so that buffer ...
… …
…
manifest file
…
where’s Madmen?
… …
Application Layer: 2-21