Design and Deployment of a Reliable File Transfer Protocol over Asymmetric Satellite Networks - PowerPoint PPT Presentation

1 / 36
About This Presentation
Title:

Design and Deployment of a Reliable File Transfer Protocol over Asymmetric Satellite Networks

Description:

Outline of the Talk. Why Satellite networks for reliable transfer ? ... 24, 30, 37.5, 49.5 and 75 Kilobytes per second. Error rate of DEP Satellite Network ... – PowerPoint PPT presentation

Number of Views:29
Avg rating:3.0/5.0
Slides: 37
Provided by: anupam1
Category:

less

Transcript and Presenter's Notes

Title: Design and Deployment of a Reliable File Transfer Protocol over Asymmetric Satellite Networks


1
Design and Deployment of a Reliable File
Transfer Protocol over Asymmetric Satellite
Networks
  • Anupam Goyal
  • Roll no. 01329001
  • Guided By
  • Dr. Sridhar Iyer

2
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

3
Satellite Networks
  • Widely used for audio-video transmissions
  • Major disadvantages
  • large delay
  • higher bit error rates
  • limited bandwidth

4
Satellite Networks for Reliable Transfer
  • Interesting for reliable data transfer to clients
    dispersed over a large area due to
  • Inherent multicast nature
  • Long reach

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

6
DEP Satellite Network
  • Very Small Aperture Terminal (VSAT) Network
  • Topology
  • 512 kbps Demand Assigned Multiple Access channel
  • 16 kbps Time Division Multiple Access channel

7
The DEP Network Setup
8
(No Transcript)
9
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.

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

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

12
Logical TDMA point to point channel
13
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.

14
The Protocol Sequence Graph
15
(No Transcript)
16
The Server State Transition Graph
17
(No Transcript)
18
The Client State Transition Graph
19
(No Transcript)
20
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.

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

22
RTAN - The Basic Protocol Server
  • Recovery Cycle
  • Reuest N bit index from the RSs 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.

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

24
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)

25
RTAN - The Basic Protocol
  • Disadvantages
  • The protocol is only as fast as the maximum
    faulting RS.
  • Limited by the number of RSs that can be
    accommodated on the control channel.

26
Deployment of RTAN on DEP Satellite Network
  • Server at IIT Bombay
  • Client at NCST, Juhu, Mumbai.

27
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

28
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

29
Experiment 1 Transfer Time vs File Size
30
Experiment 2 Transfer Time vs Packets Per
Transfer
31
Experiment 3 Transfer Time vs Data Rate
32
Experiment 2 Transfer Time vs Packets Per
Transfer for different Data Rates
33
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.

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

35
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

36
Thank You
Write a Comment
User Comments (0)
About PowerShow.com