Design and Deployment of a
Reliable File Transfer Protocol
over Asymmetric Satellite
Networks
Anupam Goyal
Roll no. 01329001
Guided By
Dr. Sridhar Iyer
Outline of the Talk








Why Satellite networks for reliable transfer ?
Reliable Multicast Transfer Strategies
DEP Satellite Network
The Problem and the proposed solution
RTAN
Deployment Problems
Field Experiments and results
Conclusions and Future Work
Satellite Networks


Widely used for audio-video transmissions
Major disadvantages –
• large delay
• higher bit error rates
• limited bandwidth
Satellite Networks for Reliable
Transfer

Interesting for reliable data transfer to
clients dispersed over a large area due
to
• Inherent multicast nature
• Long reach
Reliable Multicast Protocols

Types – based on error recovery responsibility
•
•
•
•

Sender-Initiated
•
•
Sender keeps track of all the clients
Sender Asks for ACKs periodically
Receiver-Initiated
•
•
Receiver detects packet loss through timers
Receiver sends NACKs to server
Tree Based
•
•
ACK Tree of receivers
Group leaders perform error recovery
Ring Based
•
•
Token site performs error recovery
Token passing
Various implementations : MFTP, RMTP, SRM, LBRM, MDP
etc.
DEP Satellite Network


Very Small Aperture Terminal (VSAT)
Network
Topology
• 512 kbps Demand Assigned Multiple
Access channel
• 16 kbps Time Division Multiple Access
channel
The DEP Network Setup
Satellite
Satellite dish
Viasat HUB
Comnet Noida
Remote Site
Remote Site
512 Kbps Simplex Carrier
Central Site - IIT Powai
16Kbps TDMA Control
Control Channel to Comnet Hub
3.8 Mtr. Ku-Band
Antenna
ODU
SKYLINX IDU
DAMA
HSCU IDU
DCU
DCU
VACANT SLOT
ROUTER
H.323
Data
Broadcast
Ethernet LAN
Camera, Mic,
Speaker
Recorded
lecture
Studio Type
VC System
The Requirement

To send any file reliably over the satellite
network to all or a particular receiving
station.
• Large files of the order of 1 GB : videotaped
•
lecture
Small files of the order of KBs : tutorials etc.
The Problem




The need to have TCP like reliability.
The need to send files of the order of 1
GB.
The 16 kbps full duplex reliable channel
is too small for sending large files in
reasonable time.
The 512 kbps DAMA channel is a
multicast channel and hence offers no
guarantee of reliable data delivery.
The Solution



Use the 512 kbps half duplex channel for
data transfer.
Use the 16 kbps full duplex channel for
control information exchange with the
receivers.
Design an application level UDP based
reliable file transfer protocol.
Logical TDMA point to point channel
Designed Protocol


Reliable Transfer over Asymmetric
Networks (RTAN)
Basic Idea of RTAN –
•
•
•
•
The overall transfer consists of many Transfer Cycles
Each Transfer cycle consists of one Data Cycle and
many Recovery Cycles
A fixed number of packets are sent per Data Cycle
to all the clients.
All the packets dropped by at least one client are
remulticast in Recovery Cycles until all the clients
have received all the packets sent in the Data Cycle.
The Protocol Sequence Graph
The Server State Transition Graph
The Client State Transition Graph
RTAN - The Basic Protocol: Server
Server side processing
 Start ConnectionAcceptorThread. Wait for Client
connections. Add connecting clients to a global
Connection List.
 Wait for file transfer request.
 Start KeepAlive thread.
 Start Transfer.
 Transmission setup cycle:
•
•
•
Mark all the clients in the connection list as in session.
Send file Transfer_Start message to all the clients on
control channel. Information like file name, file size etc.
Wait for ACKs.
RTAN - The Basic Protocol: Server


Start Transfer Cycle.
Data Cycle
•
•
•
•
Create transfer buffer and index.
• Read N data packets of size M bytes from the file.
• Buffer them in the memory.
• Creates a N bit send index, one bit for each packet.
• M,N pre-decided.
Send Data_Start message – start packet index, end
packet index
Wait for Acks from all clients.
Multicast N data packets on the DAMA channel.
RTAN - The Basic Protocol: Server

Recovery Cycle:
•
•
•
•
•


Reuest N bit index from the RS’s on the control channel from all
clients.
•
•
Send Send_Index message to all clients.
Wait for ACKs.
Perform boolean AND with the server send index.
Create recovery list from send buffer.
Remulticast the packets dropped by the clients.
Again request index from all clients.
If recovery list empty then transfer cycle ends
•
•
Send Recovery_End message to all clients.
Wait for ACKs.
If no more data to send then Transfer ends.
•
•
Send Transfer_End message to all clients.
Wait for ACKs.
RTAN - The Basic Protocol: Client
Client Side Processing
 Start the ControlProcessorThread and the
DataProcessorThread.
 Wait for Server messages.
•
•
•
•
•
If Transfer_Start message, create a session object.
If Data_Start message, create a buffer and N bit
index.
If Send_Index message, send index to the server.
If Recovery_End message, flush buffer to disk.
If Transfer_End message, delete session object.
RTAN - The Basic Protocol
• Contents of data packet:
• RTAN header
• Actual data bytes
• RTAN header is of 17 bytes:
• SessionID (4 bytes)
• FileID (4 bytes)
• Sequence Number (4 bytes)
• FileSize (4 bytes)
• Flags (1 byte)
RTAN - The Basic Protocol

Disadvantages:
• The protocol is only as fast as the maximum
•
faulting RS.
Limited by the number of RS’s that can be
accommodated on the control channel.
Deployment of RTAN on DEP
Satellite Network


Server at IIT Bombay
Client at NCST, Juhu, Mumbai.
Deployment Problems





The Router Configuration problem
•
Multicast group, multicast port added to router
The Time To Live problem
•
TTL value set to greater than 3
The Router Table Update problem
•
2-3 seconds of multicast route setup time
The Link Data rate Synchronization problem
•
The server throttled according to the link data rate
The Link Up-Down problem
•
Dummy KeepAlive packet were introduced
Field Experiments



Achievable data rates
•
•
Granularity of 10 ms
24, 30, 37.5, 49.5 and 75 Kilobytes per second
Error rate of DEP Satellite Network
•
•
Very low – 0.5% in good channel conditions
2%-3% in early morning hours
Data Packet Size
•
•
•
DEP Satellite Network MTU – 1500 bytes
Max Application data – 1440 bytes
17 byte RTAN header
Experiment 1: Transfer Time vs File Size
Experiment 2: Transfer Time vs Packets Per
Transfer
Experiment 3: Transfer Time vs Data Rate
Experiment 2: Transfer Time vs Packets Per
Transfer for different Data Rates
Conclusions Drawn from Field
Experiments



Effect of time spent on exchanging
control information on overall transfer
time is greater for small files.
Data rate is the main contributing factor
to the overall transfer time as against
packets per transfer.
Data rates closest to link capacity result
in maximum throughput.
Conclusions



A protocol for reliable transfer over
asymmetric networks (RTAN) has been
proposed.
Implementation of RTAN for writing a file
transfer utility for DEP satellite network.
RTAN Basic implementation works quite
well for the DEP Satellite Network owing
to very low error rates.
Future Work



To extract a reliable transport layer protocol for
asymmetric networks
To optimize the basic protocol implementation:
•
•
•
Version 1.1 Multiple Multicast Per cycle
Version 1.2 Ignore Unruly Client
Version 1.3 Regional Division of Clients
To adapt the protocol to changing DEP network
topology
Thank You