Transcript A Real-Time Video Multicast Architecture for Assured Forwarding

A Real-Time Video Multicast Architecture
for Assured Forwarding Services
Ashraf Matrawy,
Ioannis Lambadaris
IEEE TRANSACTIONS ON MULTIMEDIA , AUGUST 2005
Outline
•
•
•
•
•
•
•
Introduction
Network Model
End-to-End architecture
Rate-Adaptation algorithm
Simulation
Results
Conclusion
Introduction
• Develop an architecture for multicast realtime MPEG4 over IP networks that provide
service differentiation
• Deployment of IP multicast services over
the Internet is not rapid
– Main factor: multicast congestion control
scheme is not robust as unicast
The challenges of multicast
congestion control
• The heterogeneity of receivers’ networking
capabilities and their QoS-requirement
– Layers problem: uniform drop, all layers
assumed to follow the same multicast tree
• Maintaining the scalability of the multicast
congestion control technique is a difficult
task
Overview of the work
• Develop a multicast congestion control
scheme that relies on assured forwarding
(AF) architecture
Why AF ?
• Help build a simple end-to-end
architecture that avoids the problems of
earlier approaches to multicast congestion
control
• Not require major changes in current
router’s functionality, so deployed soon in
Internet routers
Different with IETF proposed AF
service
• For simpler experiments, don’t completely
implement the IETF proposed AF service
• Don’t consider marking/policing at the
edge routers and instead marked the
packets at the sender
Network model
• Goal:
– Provide different levels of quality to receivers
– Guaranteeing a minimum quality during congestion
• Consider IP networks that support prioritydropping as a means of providing different levels
of services
– AF-compliant router achieve that by active queue
management (AQM)
• Assume that routers can provide Congestion
Notification messages upstream to the sender
with information about router’s congestion status
Queue management for AF
• In RFC, recommends provides 4 classes
of AF and 3 drop precedence levels
• Implement priority-dropping in AF is based
on AQM techniques
• AF is usually based on variants of random
early detection (RED)
Queue management for AF
• The actions of RED based on
• We assume that AF routers support one of
RED’s extensions for service
differentiation, namely, RIO and WRED
Queue management for AF
• RIO
– RED with In/Out bits
– The number of RIO out packets can be calculated
based on packets in the whole queue (RIO-C) and out
packets only (RIO-D)
– RIO-C more protect higher priority, RIO-D more
protect lower priority
• WRED
– Weighted RED
– Use one average queue length to make dropping
decisions
Backward Explicit Congestion
Notification
• This paper uses BECN-style feedback
from router to the flow controller of the
multicast sender
• Send messages back to the sender based
on the status of every virtual queue, used
by the rate-adaptation algorithm
End-to-end architecture
rate-adaptation alg.
Congestion !!
Advantages of this architecture
• Send packets as one stream is much easier to
handle than multiple streams
• With priority dropping, ensure that a minimum
quality will be received when congestion
• Scalability is minimized when the feedback to
the sender is provided from the routers rather
than form receivers
The rate-adaptation algorithm
• Pi (t ) is the probability that virtual queue i
will generate a feedback message at time t
The rate-adaptation algorithm
• Ri (t ) is the rate (in packets/s) of layer i at
the time t
 i  Ci Pi
The rate-adaptation algorithm
• The constraints:
• Depend on
– Limitation imposed by the video encoder
– Outgoing link speed
– Minimum accepted video quality at the receiver
The rate-adaptation algorithm
• Round-Trip Time (RTT)
–
t
will depend of the sender’s estimation of
the RTT from the routers that send the
feedback information
• Feedback Suppression
– To reduce feedback, routers will send
feedback with a probability instead of sending
a feedback message for every packet
The rate-adaptation algorithm
• Calculation of Probabilities
MinMax
Max
P
(t ) are
P
(t
)
– The quantities i
and i
calculated using real-time measurements
from the network rather than an analytical
model
weight
The rate-adaptation algorithm
• Changing the Equation Parameters
– At the highest priority layer, the sender selects
MAX( P new) received during t
i
– With the constraint
, avoid the problem
where a slow portion of the receivers drag the
sending rate
– At lower priority layers, select MIN ( Pi new)
– With constraint
– Utilize receivers’ links with extra available bandwidth
The rate-adaptation algorithm
Feedback
Feedback
Simulation
• Use network simulator – ns version 2.1b8a
• One AF class, and two drop precedence
levels
• Simulations are 300s
• Ci =0.1 for both priority levels (i=1,2)
• min th and max th at the routers for these
levels are the same in all experiment
Results – a. Basic test
• Goal: check how the sender will adjust its
rate for the high-priority packets to closely
match the bandwidth available at the receiver
Results – a. Basic test
Results – b. Heterogeneity Test
• Goal: test of how the architecture deal with
heterogeneity
Results – b. Heterogeneity Test
Results – b. Heterogeneity Test
Results – b. Heterogeneity Test
Results – b. Heterogeneity Test
Results – b. Heterogeneity Test
Results – b. Heterogeneity Test
Results – C. Scalability Test
• Goal: test how the architecture handles a larger
number of receivers
• R1~15: 100kbps, R16~30: 200kbps, R31~45:
300kbps, R46~60: 400kbps
• With RIO-D
Results – C. Scalability Test
Results – C. Scalability Test
Results – C. Scalability Test
Conclusion
• Present an architecture and a rateadaptation algorithm for real-time video
transport in AF network
• Enable users with different capabilities to
receive the same video multicast in
different qualities
RED