Spacecraft Communication Delays for Distributed Software Systems

1
Spacecraft Communication Delays for Distributed
Software Systems

• Rammohan K. Ragade, Joseph Gardner, Adel
  S.Elmaghraby
• Computer Engineering and Computer Science
• University of Louisville, Louisville KY 40292

2
Space travel communications

• long space travel implies communication delays
• Delays have been predicted of the order of 40
  mins for a round trip transaction
• Protocols such as TCP/IP are for interactive
  networks, although recent advances in mobile
  communications have called for re-examination
• Protocol extension should be natural and
  appropriate

3
Problem definition

• Apply TCP/IP to an environment for which it was
  not explicitly designed- a low to moderate
  bandwidth, high latency network.(0 to 256,000
  bits per second (bps). )
• a manned space mission to Mars or beyond, the
  propagation times of a signal become significant
• significant performance decrease in TCP/IP due to
  the needs of a call set-up, window size and
  acknowledgements

4
Window size and data rate
5
Retransmission and Blackouts

• In retransmission many packets may be
  re-transmitted when only a small portion of them
  were actually damaged or missing. The result is
  poor utilization of the network due to all these
  unnecessary retransmissions. Figure 2 indicates
  a scenario where a small portion of packets (1)
  where dropped while a large number of them (4)
  were retransmitted. 3
• Blackouts can be caused by events like solar
  flares, or because something physical is between
  the Sender and Receiver, like a planet or
  asteroid for example and are common.

6
Retransmissions
7
SOLUTIONS to each factor and a quantitative model

• Call Setup Eliminate completely due to high
  cost of round trip validation.
• Sender and Receiver can still know which packets
  to expect next by following
• 1)   Sender transmits traditional SYN packet.
• 2) Sender begins transmitting data while awaiting
  SYN/ACK
• 3) The Receiver will respond with a traditional
  SYN/ACK packet and begin accepting incoming data.
• 4)  The Sender will receive this SYN/ACK replying
  in the traditional manner with an ACK of its own.
  It will continue to send the data.

8
Solution to window size

• simply increase the window size beyond the
  current 16 bits to 32 bits
• the purpose of the window size in the current TCP
  is more for controlling the flow of data from the
  Sender than representing the amount of buffer
  space available to either the Sender or Receiver.
  A high latency environment will make flow
  control in this manner quite ineffective in
  general.

9
Example of Large Window Size
10
Selective Acknowledgments (SACK).

• If the Receiver finds no packets missing, it will
  send a normal ACK to the Sender.
• However, if packets have been lost, the Receiver
  will reply with a SACK that contains the sequence
  numbers of the packets immediately before and
  after the missing packet.

11
Sample SACK transaction
12
The case study values

• i) Two data rates (r) are used 56 kbps and
  144 kbps,
• ii) Three data sizes (s) are used 50kB (400kb),
  200kB (1600kb), and 500kB (4000kb),
• iii) A range of propagation times (p) from 1 to
  10 seconds on 1-second intervals, and, iv)
  Segment size (g) will be set at 4 packets of 1024
  bytes (32,768 bits).

13
Parameters of the quantitative model

• p propagation time in seconds
• s size of data in bits,
• r the rate of transfer in bits per second,
• g segment size in bits,
• m number of segments with lost packets,
• l number of packets lost per segment, and
• k packet size in bits.
• Current standard TCP Implementation

when
14
Current (Standard) TCP Implementation
The maximum amount of data allowed outstanding at
any given time is 524,288 bits. Thus, if the
time of propagation and/or the data rate is
sufficiently high this threshold may be reached
before an acknowledgement is received. To handle
this, once data rates is sufficiently high or
latency is sufficiently long that it is
necessary to use Equation 2.
when
15
Factor 1 Call Setup modification
With round trip elimination for
and
otherwise
16
Factor 2 Window Size
Here apply Equation 1 to all cases instead of
only when .
17
Factor 3 Selective Acknowledgements
This requires assumptions about packet loss. It
is only necessary to consider the time wasted in
retransmission of correctly received packets
Segment size determines how many packets will be
retransmitted for one or more packets lost within
that segment. The loss percentage determines how
many packets are lost. Loss distribution
determines how the packet loss is concentrated
18
For Selective acknowledgements
The cost to retransmit a segment
for
Else
19
For Selective acknowledgements

• By choosing a fixed percentage of loss it is
  possible to show the time wasted in
  retransmitting correctly received packets is
  dependant on the segment size and the
  distribution of the loss among those packets.
• We shall consider two scenarios with the case
  study values of i) Packet size 1,000 bytes,
  ii) Segment sizes of a ) 5,000 bytes with 5
  packets, b) 20,000 bytes with 20 packets and c)
  100,000 bytes with 100 packets. We will also
  require a total of 500,000 bytes (500 packets)
  to be accurately transferred. We will allow a
  packet loss of 1 (5 packets) and transmit the
  data at a data rate is fixed at 56 kbps.

20
For Selective acknowledgementsScenario 1
Normal Distribution

• For this scenario, the 5 lost packets are
  distributed across 5 separate segments. The
  following table shows the number of unnecessarily
  retransmitted packets and the time required to
  send them for each of the segment sizes.

21
For Selective acknowledgementsConcentrated
Distribution

• In this scenario, all 5 lost packets are
  contained within the same segment

22
Experimental Analysis

• For the actual testing, a network emulator was
  used to emulate connection speeds, data loss, and
  latencies. NIST Net, written by the National
  Institute of Standards and Technology was chosen
  for this purpose. This emulator allows for
  specification of delay (latency) times, and the
  corresponding deviations and distributions of
  those delays. The emulator allows for dropped or
  duplicated packets based on given percentages and
  distributions. The emulator also allows for
  asynchronous bandwidth (data rate). 7

23
The emulator set-up
24
Experimental results

• Using this emulator, it is possible to create an
  environment identical to the one used in the
  Quantitative Model specifically data rates of 56
  kbps and 144 kbps, delays of 0 to 10 seconds and
  packet loss of 1.
• Charts 1 and 2 contain the results of the
  Experimental analysis over the given range of
  values with no Call Setup time and the Standard
  16-bit Window Size. These values compare very
  favorably to the expected values from the
  Quantitative Model.

25
CHART 1 Quantitative Model Transfer at 144 kbps
Full Comparison of 500 kB Transfer
26
CHART 2 Experimental Transfer at 56 kbps No
Call Setup
27
Experimental Transfer at 144 kbps No Call Setup
28
Implications for long latency space travel systems

• In interactive multimedia systems, it is
  necessary for an active communications agent to
  mediate data transfer
• The agent will have rules for data-sizing,
  selected encryption, image trimming, SACK
  re-transmissions.
• The agent will schedule transmissions to avoid
  blackouts, thus adding to the latency issues.
• Critical distributed medical decision making
  should be re-examined in the light of latency
  issues and the impact of types of communication
  protocols employed.

29
Acknowledgements

• This research was inspired by the on-going
  project supported by NASA through a Small
  Business Administrations Small Business
  Technology Transfer program to Intellas, LLC,
  Louisville KY and subcontracted to the University
  of Louisville, Louisville, KY.