ECE 356/COMPSI 356

Computer Network Architecture

Multimedia Communications

December 2 & 4, 2024 1

Current Assignments & Quizzes
• Supplementary readings provided as a PDF
• No ungraded HW exercises
➢Sample questions in last year’s final

2
 Lecture Outline
• Multimedia applications: an introduction
• Streaming stored video
• Voice-over-IP
• Network support for multimedia
• Emerging applications & hot topics

3
 Traditional Data Applications
• Web browsing, e-mail, file transfer
• “Elastic”
➢ Can work without a guarantee of timely delivery of data
➢ Benefit from shorter delays, but do not become unstable as
delays increase
• Not loss-tolerant

4
Multimedia Communications

5
 Properties of Video (1/2)
• One of primary properties: high bit rate
Bit rate Bytes transferred in 67 min
Facebook browsing 160 kbps 80 MB
Spotify audio streaming 128 kbps 64 MB
Video streaming 2 Mbps 1 Gb
• Facebook browsing: a new photo every 10 s, photos are 200 KB in
size on average

• Requirements get higher and higher as video improves

6
 Properties of Video (2/2)
• Even higher bit rates: virtual reality
➢ 360 degree videos
➢ Much higher frame rates
• RGB-D video
➢ Depth data: another stream

7
Recap: Properties of Video: Compression
• Video: a sequence of images displayed at a constant rate, e.g., 24
or 30 images per second
• 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)
➢ Temporal (from one image to next)
• Can compress the video to almost any bit rate
➢ The higher the bit rate, the better user viewing experience

8
Recap: Video Compression Examples
Spatial coding example: instead of sending N values of same color (all
purple), send only two values: color value (purple) and number of
repeated values (N)

Temporal coding
example: instead
of sending
complete frame at
i+1, send only
differences from
frame i
frame i frame i+1 9
Recap: Properties of Video: Multiple
Versions of the Same Video
• Use compression to create multiple versions of a video,
with different quality levels
➢ E.g., 300 kbps, 1 Mbps, 3 Mbps
• Users can decide which quality to choose
• Applications adapt quality to available bandwidth

10
 Properties of Audio
• Also can be compressed to multiple levels
➢ Human speed is intelligible when compressed to under 10 kpbs
➢ Common encoding rate: 128 kpbs
• Users are more sensitive to audio glitches than to video
glitches
➢ E.g., a video conference can be OK if video feed is lost once in a
while, but would likely be terminated if audio is not getting through
• Conversational audio: natural stop-and-go pattern

11
 Types of Multimedia Network Applications:
Streaming Stored Audio and Video
• Streaming: can begin playout before downloading the
entire file
• Stored (at a server): can transmit faster than audio/video
will be rendered (implies storing/buffering at client)
• Interactivity: user may pause or reposition content
➢ Need to react to the user with sufficiently low latency
• Continuous playout: data must be received from the
server in time for its playout at the client
12
 Types of Multimedia Network Applications:
Conversational Voice and Video-over-IP
• Highly delay-sensitive
➢ Interactive nature of human-to-human conversation limits delay
tolerance
➢ A few 100 ms at most
➢ E.g., for voice, 150 ms is not perceived, 150 – 400 ms is
acceptable, 400 ms + is frustrating and potentially unintelligible
• Loss-tolerant
➢ In contrast with elastic data applications
• Allowing for a range of degradations
13
Types of Multimedia Network Applications:
Streaming Live Audio and Video
• Sports event, news event
• Usually transmitted to many users simultaneously
• Less stringent requirements than conversational
multimedia
• Delays can be an issue
➢ Delays of up to ~ 10s can be tolerated

14
 Lecture Outline
• Multimedia applications: an introduction
• Streaming stored video
• Voice-over-IP
• Network support for multimedia

15
Streaming Stored Video

2. video
sent
1. video 3. video received,
recorded network delay played out at client
(e.g., 30 (fixed in this (30 frames/sec) time
frames/sec) example)

streaming: at this time, client

playing out early part of video,
while server still sending later
part of video
Streaming Stored Video: Challenges
• Continuous playout constraint: once client playout
begins, playback must match original timing
➢ … but network delays are variable (jitter), so will need client-side
buffer to match playout requirements
• Other challenges:
➢ Client interactivity: pause, fast-forward, rewind, jump through
video
➢ Video packets may be lost, retransmitted
Streaming Stored Video
constant bit
rate video client video constant bit
transmission reception rate video
playout at client
variable
network

buffered
video
delay

client playout time

delay
18
Characteristics of Playback Applications

• In general lower delay is preferable

• Doesn’t matter when packet arrives as long as it
is before playback point
• Applications can tolerate some loss

19
 Streaming Multimedia: UDP
• Server sends at rate appropriate for client
➢ Often: send rate = encoding rate = constant rate
➢ Transmission rate can be oblivious to congestion levels
• Short playout delay (2-5 seconds) to remove network jitter
• Error recovery: application-level, time permitting
• RTP [RFC 2326]: multimedia payload types
• UDP may not go through firewalls

20
 Streaming Stored Video: HTTP
• Multimedia file retrieved via HTTP GET
• Send at maximum possible rate under TCP
variable
rate, x(t)
Prefetching
video TCP send TCP application
file buffer receive playout buffer
buffer
server client

• Fill rate fluctuates due to TCP congestion control,

retransmissions (in-order delivery)
• Larger playout delay: smooth TCP delivery rate
• HTTP/TCP passes more easily through firewalls 21
Recall: Streaming Video: DASH (1/2)
• DASH: Dynamic, Adaptive Streaming over HTTP
• Server:
➢ Divides video file into multiple chunks
➢ Each chunk stored, encoded at different rates
➢ Manifest file: provides URLs for different chunks
• Client:
➢ Periodically measures 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)
22
Recall: Streaming Video: DASH (2/2)
• “Intelligence” at client: client determines
➢ When to request chunk (so that buffer starvation, or overflow
does not occur)
➢ What encoding rate to request (higher quality when more
bandwidth available)
➢ Where to request chunk (can request from URL server that is
“close” to client or has high available bandwidth)

23
 Lecture Outline
• Multimedia applications: an introduction
• Streaming stored video
• Voice-over-IP
• Network support for multimedia

24
 Voice-over-IP (VoIP)
• VoIP end-end-delay requirement: needed to maintain
“conversational” aspect
➢ Higher delays noticeable, impair interactivity
➢ < 150 msec: good
➢ > 400 msec: bad
➢ Includes application-level (packetization, playout), network delays

25
 VoIP Characteristics
• Speaker’s audio: alternating talk spurts, silent periods
➢ 64 kbps during talk spurt
➢ Packets generated only during talk spurts
• Application-layer header added to each chunk
• Chunk+header encapsulated into UDP or TCP segment
• Application sends segment into socket every 20 msec
during talk spurt
 VoIP: Packet loss, Delay
• Network loss: IP datagram lost due to network congestion
(router buffer overflow)
• Delay loss: IP datagram arrives too late for playout at
receiver
➢ Delays: processing, queueing in network; end-system (sender,
receiver) delays
➢ Typical maximum tolerable delay: 400 ms
• Loss tolerance: depending on voice encoding, loss
concealment, packet loss rates between 1% and 10% can
be tolerated 27
 Delay Jitter
constant bit
rate client constant bit
transmission reception rate playout
at client
variable

buffered
network

data
delay
(jitter)

client playout time

delay

• End-to-end delays of two consecutive packets: difference can be more

or less than 20 msec (transmission time difference)
28
 VoIP: Fixed Playout Delay
• Receiver attempts to playout each chunk exactly
q msecs after chunk was generated
➢ Chunk has timestamp t: play out chunk at t+q
➢ Chunk arrives after t+q: data arrives too late for
playout: data “lost”
• Tradeoff in choosing q:
➢ Large q: less packet loss
➢ Small q: better interactive experience
 VoIP: Fixed Playout Delay
packets

• Sender generates packets

every 20 msec during talk
spurt. first packet received at
time r packets
generated
loss

• First playout schedule: packets

received
playout schedule
p' - r
begins at p
• Second playout schedule: playout schedule
p-r

begins at p’
time

r
p p'
 Adaptive Playout Delay (1/4)
• Goal: low playout delay, low late loss rate
• Approach: adaptive playout delay adjustment:
➢ Estimate network delay, adjust playout delay at beginning
of each talk spurt
➢ Silent periods compressed and elongated
➢ Chunks still played out every 20 msec during talk spurt
 Adaptive Playout Delay (2/4)
• Adaptively estimate packet delay: (EWMA - exponentially
weighted moving average, recall TCP RTT estimate):

di = (1−)di-1 +  (ri – ti)

delay estimate small time received time sent

after ith packet constant, e.g. - (timestamp)
0.1
measured delay of ith
packet
 Adaptive Playout Delay (3/4)
• Also useful to estimate average deviation of delay, vi :

vi = (1−)vi-1 +  |ri – ti – di|

• Estimates di, vi calculated for every received packet, but used only at
start of talk spurt
• For first packet in talk spurt, playout time is:
playout-timei = ti + di + Kvi

• Remaining packets in talk spurt are played out periodically

33
 Adaptive Playout Delay (4/4)

Q: How does receiver determine whether packet is first in a talk

spurt?
• If no loss, receiver looks at successive timestamps
➢ Difference of successive stamps > 20 msec → talk spurt begins
• With loss possible, receiver must look at both time stamps
and sequence numbers
➢ Difference of successive stamps > 20 msec and sequence numbers
without gaps → talk spurt begins

34
 VoiP: Recovery from Packet Loss (1/3)
Challenge: recover from packet loss given small tolerable delay
between original transmission and playout
• Each ACK/NAK takes ~ one RTT
• Alternative: Forward Error Correction (FEC)
➢ Send enough bits to allow recovery without retransmission (recall two-
dimensional parity discussed previously)

35
 VoiP: Recovery from Packet Loss (2/3)
One possible FEC scheme:
• “Piggyback lower
quality stream”
• Send lower resolution audio
stream as redundant
information
• E.g., nominal stream PCM at 64
kbps and redundant stream
GSM at 13 kbps

• Non-consecutive loss: receiver can conceal loss

• Generalization: can also append (n-1)st and (n-2)nd low-bit rate chunk
• Small redundancy overhead
 VoiP: Recovery from Packet Loss (3/3)
Interleaving to conceal loss:
• Audio chunks divided into
smaller units, e.g. four 5
msec units per 20 msec
audio chunk
• Packet contains small units
from different chunks

• If packet lost, still have most of every original chunk

• No redundancy overhead, but increases playout delay

9-37
 Lecture Outline
• Multimedia applications: an introduction
• Streaming stored video
• Voice-over-IP
• Network support for multimedia

38
Network Support for Multimedia

9-39
 Motivation of DiffServ
• Analogy:
➢ Airline service, first class, coach, various restrictions
on coach as a function of payment
• Economics and assurances
➢ Pay more, and get better service
➢ Best-effort expected to make up bulk of traffic
➢ Revenue from first class important to economic base

40
 Basic Architecture (1/2)
• Agreements/service provided
within a domain
➢ Service Level Agreement
(SLA) with ISP
• Edge routers do traffic
conditioning
➢ Traffic shaping, policing, and
marking

Six bits from IP TOS field are taken for

Diffserv code points (DSCP)
41
 Basic Architecture (2/2)
• Core routers
➢ Process packets based on packet marking and defined per hop
behavior
• Per class behavior
➢ No per flow state or signaling
➢ Coarse-grained, class-based mechanism

42
 DiffServ Architecture Example
Shaping,
Duke policing,
marking

UNC Per-hop
behavior AT&T
Edge Core
• Another analogy: getting into an event with different types of passes 43
 At the Edge
• Traffic classification
➢Look at source, destination, other parameters
➢Assign traffic to a class
• Per-class traffic conditioning
➢Rate limiting, traffic shaping

44
 Per-hop Behaviors (PHBs)
• Default forwarding: best-effort service
• Expedited forwarding (EF)
➢ Packets should be forwarded with minimal delay or loss
• Assured forwarding (AF)
➢ Possible service: strong assurance for traffic “within
profile” and allow source to exceed profile

45
 Diffserv Service Model:
End-To-End Service

• End-to-end service must be fashioned from

multiple ISPs
➢ ISPs need to cooperate

46
 Diffserv Service Model:
Is Priority Service Actually Better?
• Problems addressed by Diffserv do not exist in networks
that have enough capacity
➢ If networks run at a moderate load, most of the time there would
be no perceived difference between a best-effort service and a
Diffserv service
• Not a great business model if you want to charge extra for
priority service
➢ Good business model if your base service is terrible
47
 Network QoS Deployment
• “Dead” at the Internet scale
➢ Mechanisms exist but are not used
• Areas of success
➢ Enterprise networks
➢ Residential uplinks
➢ Datacenter networks
• Ideas keep surfacing again and again and again
48
 Lecture Summary
• Multimedia applications: an introduction
• Streaming stored video
• Voice-over-IP
• Network support for multimedia

49