multipath rtp applying multipath communication to real time applications by: saba ahsan supervisor:...
TRANSCRIPT
Multipath RTPApplying Multipath Communication to Real time
Applications
By: Saba Ahsan Supervisor: Prof. Jörg Ott
Conducted at Comnet, Aalto University of Science & Technology
Contents
• Motivation • Problem Statement• Background• MPRTP Protocol
– Goals– Architecture– MPRTP Header Extension
• Implementation – RAMP-UP– Receiver Jitter Buffer– RAMP-UP Sender
• Testing and Results• Conclusion
Motivation
• Most transport protocols select a single path for communication flow between two end hosts, even when multiple paths exist. Such flows are unable to fully utilize the available resources.
• Multihomed clients have more than one network interface. Multipath capability refers to the simultaneous use of multiple paths through the network, which may significantly improve performance and reliability.
• In real-time communication this could would improve the end-user experience by enhancing the QoS.– Bandwidth-hungry applications such as video streaming and IP-TV can benefit from the increased,
combined throughput available to multihomed clients– retransmission of lost data is often uncharacteristic of real-time traffic because of time constraints;
multipath senders can avoid lossy paths or send redundant data over multiple paths– session-based real-time communication can benefit from the redundancy by implementing failover in
case of network failures
Problem Statement
Design a solution for the transport of real-time data while simultaneously using multiple paths on multihomed clients.
• Design of Multipath RTP (MPRTP) an extension of RTP protocol, with multipath capabilities. • Design, implementation and testing of an MPRTP based solution for video streaming to a
single receiver, when multiple paths exist between the sender and receiver.
Background
Real-Time Protocol (RTP) • RTP is an end-to-end protocol designed for transporting real-time traffic such as voice and
video, over multicast and unicast. • It uses RTCP (Real-time Control Protocol) for monitoring the transmission quality, however it
does not guarantee QoS. • It is independent of the transport and network layers.• A signalling protocol such as SIP or SDP is used for managing RTP sessions. • It does not care about congestion control or fair usage like TCP.
MPRTP Protocol
Internet Draft : https://datatracker.ietf.org/doc/draft-singh-avt-mprtp/
MPRTP Goals
• Increased ThroughputConcurrent use of paths such that the combined available capacity is higher than the capacity of any individual path
• Improved ReliabilityMPRTP should be able to transmit redundant streams on different paths for reliability and support fallback in case of path failures for robustness.
• Compatibility– Application Compatibility: MPRTP stack must be capable of working with legacy RTP
applications. – Network Compatibility: MPRTP subflows should appear as RTP flows and be able to
traverse through NATs and Firewalls.
Architecture
Application
MPRTP
RTP RTP … RTP
UDP/TCP UDP/TCP … UDP/TCP
IP IP … IP
Physical Physical … Physical
• Each path represents an MPRTP subflow.• Like RTP, MPRTP can work with different transport protocols.
MPRTP Specification• Path Management
Path awareness and management of port+IP pair bindings. MPRTP is designed to use in-band signaling for path advertisements and/or connectivity checks. Interface discovery may be done using ICE.
• Packet SchedulingSplitting of data into multiple subflows across different paths.
• Subflow recombinationRecombining the subflows, so that it appears as a single stream to the application
MPRTP Sender
MPRTP Receiver
Internet
subflow 1 subflow 1
subflow 2
subflow 3
subflow 2
subflow 3
MPRTP Flow
Gather characteristics of different paths and schedule packets accordingly
Reorder the data correctly and hand over to application, send reports about quality
MPRTP Header Extension for RTP• RTP sequence numbers used for packet reordering of the stream • Flow-specific sequence numbers increase monotonically for each path, independent of other
paths.
0 1 2 3 4 5 6 7 8 910 1 2 3 4 5 6 7 8 9
20 1 2 3 4 5 6 7 8 9
30 1
V=2 P X CC M PT Sequence number
Timestamp
Synchronization source (SSRC) identifier
Contributing source (CSRC) identifiers……
RTP H-Ext ID length MPR_Type
Flow ID Flow specific sequence number
RTP payload…….
MPRTP Implementation
RAMP-UPRTP Adaptation for Multiple Paths – Using Percentage
distribution
• Ordering is based on overall sequence number. • Packets are inserted into the jitter buffer as soon as they arrive. • Playout starts after a predefined latency period. We use 2 seconds for our testing. • Late packets are discarded
9 58 6 4
07 3 2 1
Time
Path 1
Path 2
Reordering in Jitter Buffer 9 58 6 4 07 3 2 1
RAMP-UP Receiver
• RAMP-UP sender is designed for video streaming across multiple paths. • We assume that the bitrate of the video is higher than the bitrate of any of the available
paths and hence it is necessary to use more than one path. • A common bottleneck may exist. However, if it is common to all available paths, then
congestion/losses can not be avoided. • The sender is not capable of reducing video bitrate. • We utilize a non-aggressive approach, which implies that we do not put more traffic on a path
unless necessary. This in turn implies that the full capacity of certain paths may never be known.
RAMP-UP Sender (1)
• RAMP-UP uses percentage distribution on the paths. Percentages are assigned according to measured characteristics. This approach eliminates flapping and ensures equal distribution of traffic on all paths if video rate is increased.
• Measurements are based on data gathered by RTCP reports. • All packets of a frame are sent on the same path. • Initially, equal percentage is assigned to each path.
RAMP-UP Sender (2)
Path 1 Queue
To Receiver
Sender’s Buffer
Decision based on percentage level
Path 2 Queue
• Using RTCP reports, the sender is able to calculate the bitrate observed on each path (TBi)• The observed bitrate depends on the amount of traffic being sent on the path, hence the
sender would only update bitrate values if they are higher than what was previously recorded, except if the ratio of lost packets (Li) is greater than 0 in the RTCP RR.
• Average packet size (Si) is calculated for each interval during which the bitrate was measured.• If a path has continuous losses, it is considered congested, and in this case the observed
bitrate is stored in another variable called CBi .
• The sender assigns a percentage of traffic to each path using TBi values if path is not congested, and CBi value if path is congested.
• Congestion condition is cleared if losses don’t appear for a predefined amount of time ( in our testing we use 25 seconds)
RAMP-UP Sender (3)
RAMP-UP Sender (4)
HSN = 1000
HSN2 = 2300, t2
HSN1 = 1000, t1
t2 -t1
HSN = 2300
Sender Receiver
RTPRTCP
Testing & Results
Test Setup• The test environment consists of virtual machines running on a single physical machine. • Network properties are emulated using Network Emulator (NetEm)
MPRTP Sender
MPRTP Receiver
Router1
Router2
Router3
Virtual Environment
Results: Bitrate of data being sent on each path as measured by the sender when three paths are available. Path capacities are changed during simulation.
Time (s)
Bitr
ate
(kpb
s)
Results: Percentages assigned to the paths over timeTotal Packets lost = 1.6%, Frames lost = 6%, BER = 1.8%
Time (s)
Assi
gned
Rati
os
Conclusion
• It is possible to achieve higher bitrates using multiple paths, which may help streaming higher quality videos.
• The extra paths may be used to avoid losses due to temporary congestion on any of the paths.
• Video streaming, is just one of the many applications of MPRTP. • MPRTP protocol is still in its infancy. • RAMP-UP focuses on video streaming only. The scheduling algorithm can be improved
further. Multiple streams (voice/video, lip-sync) and rate-control mechanism can be incorporated.
• Many research opportunities arise from this study– MPRTP for mobile environments, 3G, GPRS & WLAN interfaces– MPRTP for voice fallback