impact of satellite networks on transport layer protocols
DESCRIPTION
TRANSCRIPT
SATELLITE NETWORKING PRINCIPLES AND PROTOCOLS;
IMPACT OF SATELLITE NETWORKS ON
TRANSPORT LAYER PROTOCOLS
Advisor: Dr. Nemaney pourPrepared By: Reza Ghanbari Maman
December 2010
OUTLINE
Introduction
TCP performance Analysis
Slow Start Enhancement
Loss recovery enhancement
Enhancements using interruptive
mechanisms
Voice over IP
Real-time transport protocol
INTRODUCTION
Transport Communication Protocol The end to end protocol between processes in
different hosts across internet networks. It is transparent to the internet. The most challenging task is to provide reliable
and efficient transmission services without knowing anything about application above it or anything about the internet below it.
Application
Host parameters
Configurations
Channel
TCP control
INTRODUCTION
Application CharacteristicsRemote loginFile transferWorld wide web and e-mail
Client and server host parameters Process power Buffer sizes Speeds of NIC’s Round Trip Time (RTT)
Satellite network configurations Assumption :
Constraints: Long delay, Errors, Limited bandwidth, etc.
Access networks and internetworking units are capable of dealing with traffic flows
Application
Host Parameters
Configurations
Channel
TCP control
INTRODUCTION
Application
Host Parameters
Configurations(Cont.)
Channel
TCP control
Asymmetric satellite networks Forward direction : From satellite gateway station
to user stations Return direction: User stations to satellite
gateway station Data rate in the forward direction is larger than
the return direction, because of limits on the transmission power and the antenna size at different satellite earth stations
Receive-only broadcasting satellite systems: Unidirectional It can be used as non-satellite return path The nature of most TCP traffic is asymmetric with data
flowing in one direction and acknowledgements in the opposite direction
DVB-S, DVB-RCS and VSAT satellite networks
INTRODUCTION
Application
Host Parameters
Configurations(Cont.)
Channel
TCP control
Satellite link as last hop Provide directly service as opposed to satellite
links located in the middle of a network, may allow for specialized design of protocols used over the last hop.
Providers use; Satellite link as shared high-speed downlink to users
with a lower speed Non-shared terrestrial link as a return link for
requests and ACK’s
Hybrid satellite networks Typical configuration Satellite links
Locate at any point in the network topology Act as another link between two gateways
Connection may be sent over terrestrial links (including terrestrial wireless), as well as satellite links
INTRODUCTION
Application
Host Parameters
Configurations(Cont.)
Channel
TCP control
Point-to-point satellite networks Pure Configuration Only hop is over the satellite link
Multiple satellite hops Network traffic may traverse multiple hops
between source and destination which aggravates the satellite characteristics
Generic problem because of many more constraints due to long delay, error and bandwidth
Constellation satellite networks Without Inter Satellite Links
Wide coverage is achieved by multiple satellite hops With Inter Satellite Links
wide coverage is achieved by ISL Problem:
Dynamic network routing Variable end-to-end delay
INTRODUCTION
Application
Host Parameters
Configurations
Channel
TCP control
Internet consists of various topologies, bandwidth, delays and packet sizes
TCP defined in RFC793, RFC1122, RFC1323 It is a byte stream (Not a message stream) Message boundaries are not end to end
preserved It is full-duplex connection and point to point It does not support multicasting or broadcasting The sending and receiving entities exchange
data in the form of segments Segment of TCP
Fixed 20-bytes header followed by zero or more data bytes
Size limitationsEach segment fit into 65,535 bytes IP/v4 payload
and Maximum Transfer Unit (MTU)
INTRODUCTION
Application
Host Parameters
Configurations
Channel (Cont.)
TCP control
TCP and satellite channel characteristics Long Round Trip Time (RTT)
Due to the propagation delay Determination of successfully received at the final
destination may take a long time for a TCP sender Large Delay Bandwidth product
Due to the bottleneck link It defines the amount of data a protocol should have
data that has been transmitted but not yet acknowledged (called In-Flight)
Variable Round Trip Times It is a variable propagation delay to and from the
satellite in LEO constellations Affects to Retransmission Time Out (RTO)
Alternate connectivity This may cause packet loss in non-GSO satellite
orbit configurations
INTRODUCTION
Application
Host Parameters
Configurations
Channel (Cont.)
TCP control
TCP and satellite channel characteristics (Cont.) Asymmetric use
Due to the expense of the equipment used to send data to satellites
Situated that the uplink has less available capacity than the downlink for return channel
May have an impact on TCP performance Transmission errors
Bit Error Rate (BER) Satellite channels higher than typical terrestrial
networks TCP assumes
network congestion encloses to all packet drops Moderated by reduction of window size Avoided by assigning that the drop was due to it
INTRODUCTION
Application
Host Parameters
Configurations
Channel
TCP control
TCP Control Flow control
To ensure the transmitted data is at a rate consistentShared capacity of a link among the connections
using it Result
Most throughput issues are exhausted Congestion Control
Used to avoid generating network traffic Mechanisms
Slow startCongestion avoidanceFast retransmit before RTO expiresFast recovery to avoid slow start
INTRODUCTION
Application
Host Parameters
Configurations
Channel
TCP control (Cont.)
TCP Control Characteristics
Congestion Window (cwnd) Higher priority to inject into the network before
receiving an ACK The value is limited to the receiver’s advertised
window size Slow Start Threshold (ssthresh)
If cwnd < ssthresh then the Slow-Start Algorithm is used to increase the value of cwnd
If cwnd >= ssthresh then Congestion Avoidance Algorithm is used
The initial value is the receiver’s advertised window size and is set when congestion is detected
Negative impact on the performance Because of slow probe to the network for additional
capacity and wastes bandwidth It is true over long-delay satellite channels
because of more time consumption to obtain feedback from the receiver
TCP PERFORMANCE
ANALYSIS
First Transmission
Slow Start Trans.
Congestion Avoidance Trans.
Usage of satellite link as satellite networks Expensive Time consumption to implement
Analysis and calculation of bandwidth utilization over a point-to-point satellite network as; First TCP Transmission TCP Transmission in Slow Start Stage TCP Transmission in Congestion Avoidance Stage
First Transmission
Slow Start Trans.
Congestion Avoidance Trans.
: Data to transmit
: Propagation Delay
: Bandwidth capacity
: Utilization
First TCP Transmission
Bandwidth Utilization
Complete data transmission
TCP transmission in slow start Stage Let where n is the total number of RTT
Bandwidth Utilization
U
DB
bT TCP PERFORMANCE
ANALYSIS
First Transmission
Slow Start Trans.(Cont.)
Congestion Avoidance Trans.
: Data to transmit
: Propagation Delay
: Bandwidth capacity
: Utilization
TCP transmission in slow start Stage(Cont.)
Complete data transmission
General Transmitted date size where 0 ≤ < 1
Link Utilization
General Complete data transmission
U
DB
bT TCP PERFORMANCE
ANALYSIS
First Transmission
Slow Start Trans.
Congestion Avoidance Trans.
TCP transmission in congestion avoidance stage
Transmitted data size where m is maximum size
Link Utilization
where 0 ≤ β < 1
Window Size
TCP PERFORMANCE
ANALYSIS
TCP for trans.
Slow-Start &
Delayed ACK
Larger initial window
Slow-Start
Termination
Optimization of TCP performance Major problem of TCP
Unknown total data size Unknown available bandwidth Unknown carry process of TCP segment
SLOW-START ENHANCEMENT
TCP for trans.
Slow-Start &
Delayed ACK
Larger initial window
Slow-Start
Termination
Optimization of TCP performance (Cont.)
Rules and parameters Increase minimum segment size of
Limitations Slow-Start threshold Congestion window size Receiver buffer size
Improve Slow-Start algorithm Limitation
Slow transmission Improve ACK
Limitation Buffer Space
Detect packet loss due to transmission error Limitation
ACKs transmitted at different paths Improve congestion avoidance mechanism
Limitation Slow transmission
SLOW-START ENHANCEMENT
bT
TCP for trans.
Slow-Start &
Delayed ACK
Larger initial window
Slow-Start
Termination
TCP enhancement techniques For short request/response traffic, utilization
affected by Connection set-up
Using three-way handshake (with Synchronization number-SYN)
Requiring 1 to 1.5 RTTUsing TCP extensions to eliminate
Connection close-down time
Bandwidth utilization At small data size transactions
Very low Improvement
Ability to share the same bandwidth
SLOW-START ENHANCEMENT
TCP for trans.
Slow-Start &
Delayed ACK
Larger initial window
Slow-Start
Termination
Slow start and delayed acknowledgement (ACK) Slow-Start algorithm
Used by TCP to increase the size of congestion window Used to making safe against transmitting an inappropriate
amount of data into the network when the connection starts up Waste network capacity due to large DB product
Delayed ACK receivers refrain from acknowledging every incoming data
segment Every second full-sized segment is acknowledged
If it does not arrive within a timeout, then an ACK must be generated (Timeout <500 ms)
by increasing of cwnd size, the number of ACKs slows the cwnd growth rate may decrease
a second segment must arrive before an ACK is sent
Note: The receiver is always forced to wait for the delayed ACK timer to expire before acknowledging the first segment which also increases the transfer time
SLOW-START ENHANCEMENT
TCP for trans.
Slow-Start &
Delayed ACK
Larger Initial Window
Slow-Start
Termination
Larger Initial Window By increasing the initial value of cwnd
More packets are sent during the first RTT of data transmission,
More ACKs, allowing the congestion window to open more rapidly.
By sending at least two segments initially First segment does not need to wait for the delayed ACK
timer to expire as is the case when the initial size of cwnd is one segment
Using a fixed larger initial congestion window decreases the impact of a long RTT on transfer time A mechanism is required to limit the effect of these bursts.
Using delayed ACKs only Offers an alternative way to immediately ACK the first
segment of a transfer Opens the congestion window more rapidly
Note: The value of cwnd saves the number of RTT and a delayed ACK timeout
SLOW-START ENHANCEMENT
TCP for trans.
Slow-Start &
Delayed ACK
Larger Initial Window
Slow-Start
Termination
Termination of Slow Start When TCP detects congestion When the size of cwnd reaches the size of the
receiver’s advertised window When cwnd grows beyond a certain size When the cwnd reaches the reduced ssthresh
Notes: TCP ends slow start and begins using the
congestion avoidance algorithm when it reaches the slow-start threshold (ssthresh)
Terminating at the right time is useful to avoid overflowing the network
Avoiding multiple dropped segments
SLOW-START ENHANCEMENT
TCP for trans.
Slow-Start &
Delayed ACK
Larger Initial Window
Slow-Start
Termination(Cont.)
Termination of Slow Start (Cont.)
Packet-pair algorithm
observes the spacing between the first few returning ACKs
Determines the bandwidth of the bottleneck link
Together with the measured RTT
Determining DB product is determined
Setting ssthresh the value
SLOW-START ENHANCEMENT
Fast re-trans. & fast
recovery
Selective ACK
SACK based
enhancement
ACK congestion control
ACK filtering
Explicit congestion
notification
Detecting corruption loss
Congestion avoidance
enhancement
Loss Recovery Enhancement Satellite paths
Higher error rates than terrestrial linesCausing errors in data transmissions to be
retransmittedTCP typically interprets loss as a sign of
congestion and goes back into the slow start
Prevents TCP going to slow start unnecessarily when data segments get lost due to error
NewReno TCP algorithm is used ,but independent from the availability of Selective ACK
Note: we need to reduce the error rate to a level acceptable to TCP or find TCP knowing that datagram loss is due to transmission errors, not congestion
LOSS RECOVERY ENHANCEMENT
Fast re-trans. & fast
recovery
Selective ACK
SACK based
enhancement
ACK congestion control
ACK filtering
Explicit congestion
notification
Detecting corruption loss
Congestion avoidance
enhancement
Fast Retransmission and Fast Recovery TCP segments may not reach the other end
connection, and TCP uses timeout mechanisms to detect those missing segments, hence TCP assumes that segments are dropped due to network congestion Result: ssthresh being set to half the current value of
cwnd and its size is being reduced to the size of one TCP segment
Avoids the unnecessary process of backward process of Slow Start when a segment fails to reach the intended destination
Detects the loss of segments by using duplication of ACKs
Used to retransmit the missing data segment Result: TCP can use to resume the normal
transmission process via the congestion avoidance phase instead of slow start as before
LOSS RECOVERY ENHANCEMENT
Fast re-trans. & fast
recovery
Selective ACK
SACK based
enhancement
ACK congestion control
ACK filtering
Explicit congestion
notification
Detecting corruption loss
Congestion avoidance
enhancement
Selective Acknowledgement When multiple segments are lost within a
single transmission window, TCP performs poorly Limitation
TCP can only learn of a missing segment per RTTLack of cumulative acknowledgementsReduction of TCP throughout
Improves TCP performance Identifies missing TCP segments and
retransmits within a single RTT
Note: Due to occasional high bit-error rates (BER) of the channel, the sender is notified about which segments have not been received and need to be retransmitted by received sequence numbers
LOSS RECOVERY ENHANCEMENT
Fast re-trans. & fast
recovery
Selective ACK
SACK based
enhancement
ACK congestion control
ACK filtering
Explicit congestion
notification
Detecting corruption loss
Congestion avoidance
enhancement
SACK based enhancement mechanisms Algorithm starts after Fast Retransmit triggers
the resending of a segment Algorithm reduces cwnd into half of the size
when a loss is detected Algorithm keeps a PIPE variable
Which is an estimate of the number of outstanding segments
Which is decremented by one segment for each duplicate ACK that arrives with new SACK information
Which is incremented by one for each new or retransmitted segment sent
Algorithm recovers multiple segment losses in a window of data within one RTT of loss detection
LOSS RECOVERY ENHANCEMENT
Fast re-trans. & fast
recovery
Selective ACK
SACK based
enhancement
ACK congestion control
ACK filtering
Explicit congestion
notification
Detecting corruption loss
Congestion avoidance
enhancement
ACK congestion control In high asymmetric networks (VSAT)
low-speed return link on a high-speed forward link If a terrestrial modem link is used as a reverse
link, ACK congestion as the speed of the forward link is increased
The flow of ACKs can be restricted on the low-speed link by the bandwidth of the link by the queue length of the router
Note: The Current congestion control mechanisms are aimed at controlling the flow of data segments, but do not affect the flow of ACKs
LOSS RECOVERY ENHANCEMENT
Fast re-trans. & fast
recovery
Selective ACK
SACK based
enhancement
ACK congestion control
ACK filtering
Explicit congestion
notification
Detecting corruption loss
Congestion avoidance
enhancement
ACK Filtering It is designed
to address the same ACK congestion effects to operate without host modifications
It takes advantage of the cumulative ACK structure of TCP
It is implemented by the modified bottleneck router in the reverse direction
It is used to produce significant sender bursts by modification of Sender Adaption (SA)
Explicit Congestion Notification (ECN) It allows routers to inform TCP senders about
imminent congestion without dropping segments
LOSS RECOVERY ENHANCEMENT
Fast re-trans. & fast
recovery
Selective ACK
SACK based
enhancement
ACK congestion control
ACK filtering
Explicit congestion
notification (Cont.)
Detecting corruption loss
Congestion avoidance
enhancement
Explicit Congestion Notification (Cont.)
Forms Backward ECN (BECN)
BECN router transmits messages directly to the data originator informing it of congestion
IP routers can accomplish this with an ICMP source quench message
The arrival of a BECN signal may or may not mean that a TCP data segment has been dropped, but it is a clear indication that the TCP sender should reduce the value of cwnd
Forward ECN (FECN)FECN routers mark data segments with a special
tag when congestion is imminent, but forward the data segment
The data receiver then shows the congestion information back to the sender in the ACK packet
LOSS RECOVERY ENHANCEMENT
Fast re-trans. & fast
recovery
Selective ACK
SACK based
enhancement
ACK congestion control
ACK filtering
Explicit congestion
notification (Cont.)
Detecting corruption loss
Congestion avoidance
enhancement
Detecting Corruption Loss Corruption Loss
TCP should retransmit the damaged segment as soon as its loss is detected; there is no need for TCP to adjust its congestion window i.e. it should immediately reduce its congestion window to avoid making the congestion worse
May be detected using the fast retransmit algorithm or by the expiration of TCP’s retransmission timer
Problem It is more common than on terrestrial networks
SolutionAdding Forward Error Correction (FEC) to the
data but it can not be universally applied Corrupted TCP segment
Dropped by intervening routers Survive without detection until it arrives at the TCP
receiving host Does not indicate congestion
LOSS RECOVERY ENHANCEMENT
Fast re-trans. & fast
recovery
Selective ACK
SACK based
enhancement
ACK congestion control
ACK filtering
Explicit congestion
notification (Cont.)
Detecting corruption loss
Congestion Avoidance
Enhancement
Congestion avoidance enhancement In the absence of loss, the TCP sender adds
approximately one segment to its congestion window during each RTT
Problem Unfair sharing of bandwidth when multiple
connections with different RTTs traverse the same bottleneck link, with the long RTT connections
Solution Deployment of fair queuing and TCP-friendly
buffer management in network routers Policy changes
The “constant-rate” increase policy attempts to equalize the rate at which TCP senders increase their sending rate during congestion avoidance
The “increase-by-K” policy can be selectively used by long RTT connections in a heterogeneous environment
LOSS RECOVERY ENHANCEMENT
TCP Spoofing
Cascading or Split
TCP
Perfect Solution
Enhancements for satellite networks using interruptive mechanisms
Interruptive Mechanism
ENHANCEMENTS USING INTERRUPTIVE MECHANISMS
TCP Spoofing
Cascading or Split
TCP
Perfect Solution
TCP Spoofing Helps to improve TCP performance over
satellite Problem
The router must do a considerable amount of work after it sends an acknowledgement
Spoofing requires symmetric paths: the data and acknowledgements must flow along
the same path through the router Spoofing is vulnerable to unexpected failures
If a path changes or the router crashes, data may be lost
Spoofing does not work if the data in the IP datagram are encrypted Because the router will be unable to read the TCP
header
ENHANCEMENTS USING INTERRUPTIVE MECHANISMS
TCP Spoofing
Cascading or
Split TCP
Perfect Solutions
Cascading TCP or Split TCPTCP running over the satellite link can be
modified, with knowledge of the satellite’s properties, to run faster
Because each TCP connection is terminated, cascading TCP is not vulnerable to asymmetric paths
Perfect Solutions Satellite Networking
Should be able to meet the requirements of user applications,
Takes into account the characteristics of data traffic
Makes full use of network resources
ENHANCEMENTS USING INTERRUPTIVE MECHANISMS
TCP Spoofing
Cascading or
Split TCP
Perfect
Solutions(Cont.)
Perfect Solutions (Cont.)
Solutions
Based on the enhancement of existing TCP mechanisms have reached their limits as No knowledge about applications No knowledge about networks and hosts
Finding new techniques to achieve multi-layer and cross-layer optimization of protocol architecture
ENHANCEMENTS USING INTERRUPTIVE MECHANISMS
TCP Spoofing
Cascading or
Split TCP
Perfect
Solutions(Cont.)
Perfect Solutions (Cont.)
Solutions
Based on the enhancement of existing TCP mechanisms have reached their limits as No knowledge about applications No knowledge about networks and hosts
Finding new techniques to achieve multi-layer and cross-layer optimization of protocol architecture
ENHANCEMENTS USING INTERRUPTIVE MECHANISMS
Gateway
Decomposition
Protocols
Gatekeepers
MMC
Conference
Control
Based on RTP, IP telephony is becoming a mainstream application moving away from proprietary solutions to standards based solutions, providing QoS comparable to the PSTN and providing transparent interoperability of the IP and PSTN networks
Gateway Decomposition The signaling gateway is responsible for
signaling between end users on either network. On the PSTN side, an IP signaling protocol such as SIP or H.323, and transported across the IP network
SAP Announces the session
SDP Describes the call (or session)
VOICE OVER IP
Gateway
Decomposition
Protocols
Gatekeepers
MMC
Conference
Control
Gateway Decomposition (Cont.) Media gateway
Data, video and audio stream transfer responsibility once a call is set up
On the PSTN side, media transport is by PCM-encoded data on TDM streams;
On the IP network side, media transport is by PCM-encoded data on RTP/UDP
Media gateway controller Controls one or more media gateways
Protocols H.323 (s)
Introduced by ITU Provide multimedia capability over the Internet
RTP,RTSP, RTCP, Megaco, SIP and SDP Introduced by IETF Provide the foundation for standards based IP
telephony
VOICE OVER IP
Gateway
Decomposition
Protocols
Gatekeepers
MMC
Conference
Control
Gatekeepers Are responsible for addressing, authorization
and authentication of terminal and gateways, bandwidth management, accounting, billing and charging
Provide call-routing services
Note: Terminal is a PC or stand-alone device running multimedia applications. Multipoint control units (MCU) provide support for conferences of three or more terminals.
VOICE OVER IP
Gateway
Decomposition
Protocols
Gatekeepers
MMC
Conference
Control
Multimedia conferencing (MMC) One of the typical example applications based
on IP multicast Components
Voice provides packet audio in time slices, numerous audio-coding schemes, redundant audio for repair, unicast or multicast, configurable data rates
Video provides packet video in frames, numerous video-coding schemes, unicast or multicast, configurable data rates
Network Text Editor can be used for message exchanges
Whiteboard can be used for free-hand drawing
VOICE OVER IP
Gateway
Decomposition
Protocols
Gatekeepers
MMC
Conference
Control
Conference control provides functions and mechanisms for users to
control how to organize, manage and control a conference
Control function Floor control: Who speaks? Chairman control?
Distributed control? Loose control: One person speaks, grabs channel Strict control: Application specific, e.g. lecture Resource reservation: Bandwidth requirement and
quality of the conference Per-flow reservation: Audio only, video only, audio
and video
VOICE OVER IP
REAL-TIME TRANSPORT PROTOCOL
Internet protocols Specified for the transmission of raw data between
computer systems The emergence of modern applications and mainly
those based on real-time voice and video present new requirements to the IP protocol suite
Products support streaming audio, streaming video and audio-video conferencing
Basic of RTP Real time transport protocol
Provides end-to-end network transport functions suitable for applications transmitting real-time data.
RTP does not Address resource reservation Guarantee QoS for real-time services
Basic of RTP
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP
protocols for SI
SDS
Basic of RTP(Cont.)
RTCP(real-time transport control protocol): Allows monitoring of the data delivery in a manner
scalable to large multicast networks Provides minimal control and identification
functionality Applications run RTP on top of UDP:
Make use of its multiplexing and checksum services.
There are two closely linked parts: RTP, to carry data that has real-time properties RTCP, to monitor the quality of service and to
convey information about the participants in an ongoing session
Basic of RTP(Cont.)
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP
protocols for SI
SDS
REAL-TIME TRANSPORT PROTOCOL
Basic of RTP(Cont.)
Property ability of one party to signal to one or more other
parties and initiate a call Session Invitation Protocol
a client-server protocol that enables peer users to establish a virtual connection between them and then refers to a RTP session carrying a single media type.
Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services
IP headerUDP
headerRTP
headerData
Basic of RTP(Cont.)
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP
protocols for SI
SDS
REAL-TIME TRANSPORT PROTOCOL
Basic of RTP(Cont.)
Components End system
An application that generates the content to be sent in RTP packets and/or consumes the content of received RTP packets
Mixer An intermediate system that receives RTP packets
from one or more sources combines the packets in some manner and then forwards a new RTP packet
Translator An intermediate system that forwards RTP packets
with their synchronization source identifier intact Monitor
An application that receives RTCP packets sent by participants in an RTP session, in particular the reception reports, and estimates the current QoS for distribution monitoring, fault diagnosis and long-term statistics
Basic of RTP(Cont.)
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP
protocols for SI
SDS
REAL-TIME TRANSPORT PROTOCOL
Basic of RTP(Cont.)
RTP header format V 2-bits, version number (=2) P 1-bit indicates padding X 1-bit indicates extension header present CC 4-bits, Number of CSRCs (CRSC count) M 1-bit, profile specific marker PT 7-bits, payload type, profile specific SSRC synchronization source CSRC contributing source Timestamp has profile/flow-specific units
Basic of RTP(Cont.)
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP
protocols for SI
SDS
REAL-TIME TRANSPORT PROTOCOL
RTP control protocol Based on the periodic transmission of control packets
to all participants in the session, using the same distribution mechanism as the data packets
Performance functions Primary function provides feedback on the quality
of the data distribution RTCP carries a persistent transport-level identifier
for an RTP source called the canonical name or CNAME
The first two functions require that all participants send RTCP packets, therefore the rate must be controlled in order for RTP to scale up to a large number of participants
Optional function is to convey minimal session control information
Basic of RTP
RTP Control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP
protocols for SI
SDS
REAL-TIME TRANSPORT PROTOCOL
Sender report (SR) packets1. The first section (header) consists of the following fields.
I. Version (V)II. Padding (P)III. Reception report count (RC)IV. Packet type (PT)V. LengthVI. SSRC
2. The second section, the sender information, is 20 octets long and is present in every sender report packet.
I. NTP timestampII. RTP timestampIII. Sender’s octet count
3. The third section contains zero or more reception report blocks depending on the number of other sources heard by this sender since the last report.
I. Fraction lostII. Cumulative number of packets lostIII. Extended highest sequence number receivedIV. Inter-arrival jitterV. Last SR timestamp (LSR)VI. Delay since last SR (DLSR)
Basic of RTP
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP
protocols for SI
SDS
REAL-TIME TRANSPORT PROTOCOL
Receiver report (RR) packets The format of the receiver report (RR) packet
the same as that of the SR packet except that the packet type field contains the constant 201 and the five words of sender information are omitted
The same as SR packet except that the packet type field contains the constant 201 and the five words of sender information are omitted
Source description (SDES) RTCP packet SDES packet
A three-level structure composed of a header and zero or more chunks, each of which is composed of items describing the source identified in that chunk.
Chunk Consists of an SSRC/CSRC identifier which carry
information about the SSRC/CSRC Starts on a 32-bit boundary
Basic of RTP
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP
protocols for SI
SDS
REAL-TIME TRANSPORT PROTOCOL
Source description (SDES) RTCP packet(Cont.)
Item Consists of an eight-bit type field describing the
length of the text and the text itself. System sends one SDES packet containing its
own source identifier Mixer sends one SDES packet containing a
chunk for each contributing source from which is receiving SDES information or multiple complete SDES packets
Basic of RTP
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP
packet(Cont.)
SAP & SIP protocols
for SI
SDS
REAL-TIME TRANSPORT PROTOCOL
SAP and SIP protocols for session initiations Session Announcement Protocol (SAP)
Session creator merely multicasts packets periodically to a well-known multicast group carrying an SDP description of the session that is going to take place
Gets a little more complex when we take security and caching into account
Session Initiation Protocol (SIP) Works like making a telephone call Finds the person you are trying to reach and causes
their phone to ring Able to call traditional telephone numbers Users may move to a different location
Basic of RTP
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP
protocols for SI
SDS
REAL-TIME TRANSPORT PROTOCOL
SAP and SIP protocols for session initiations(Cont.)
A typical SIP call of initiate and terminate session
Basic of RTP
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP protocols
for SI(Cont.)
SDS
REAL-TIME TRANSPORT PROTOCOL
SAP and SIP protocols for session initiations(Cont.)
A typical SIP call using a redirect server and location server
A typical SIP call using a proxy server and location server
Basic of RTP
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP protocols
for SI(Cont.)
SDS
REAL-TIME TRANSPORT PROTOCOL
Session directory service (SDS) Multicast services growing and leading
applications to some navigation difficulties Creation of a session directory service
Functions A user creating a conference needs to choose a
multicast address that is not in useBy allocating addresses with respect to a Pseudo-
Random strategyMulticasting the session information out and if it
detects a clash from an existing SA, it changes its allocation
Users need to know what conferences there are on the multicast backbone (Mbone), what multicast addresses they are using, and what media are in use on them
Basic of RTP
RTP control
protocol
Sender Report
Receiver Report
SDES-RTCP packet
SAP & SIP
protocols for SI
SDS
REAL-TIME TRANSPORT PROTOCOL
THANKS
Any Question?