Impact of Satellite Networks on Transport Layer Protocols

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


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


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.


: 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.)


: 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.


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


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


bT

TCP for trans.

Slow-Start &

Delayed ACK


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


TCP for trans.

Slow-Start &

Delayed ACK


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


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


TCP for trans.

Slow-Start &

Delayed ACK


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


TCP for trans.

Slow-Start &

Delayed ACK


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


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


recovery

Selective ACK

SACK based

enhancement


ACK filtering

Explicit congestion

notification



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



recovery

Selective ACK

SACK based

enhancement


ACK filtering

Explicit congestion

notification



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



recovery

Selective ACK

SACK based

enhancement


ACK filtering

Explicit congestion

notification



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



recovery

Selective ACK

SACK based

enhancement


ACK filtering

Explicit congestion

notification



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



recovery

Selective ACK

SACK based

enhancement


ACK filtering

Explicit congestion

notification



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



recovery

Selective ACK

SACK based

enhancement


ACK filtering

Explicit congestion

notification (Cont.)



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



recovery

Selective ACK

SACK based

enhancement


ACK filtering

Explicit congestion




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



recovery

Selective ACK

SACK based

enhancement


ACK filtering

Explicit congestion



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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


THANKS

Any Question?

Impact of Satellite Networks on Transport Layer Protocols

Technology

congestion

transmissionslow

propagation

satellite

start amp

start algorithm

start terminationoptimization

introductionapplicationhost