Transcript Study of Transport Layer Protocol for InterPlaNetary Internet

Study of Transport Layer Protocol
for InterPlaNetary Internet
Wenbin Ma
Contents









Introduction
IPN Architecture
Communication Suite
Challenges
Why not current design
Protocol: TCP Planet
Protocol: Licklider Transmission Protocol
Network Layer Issues
References
Some Fast Facts

Time taken by light
Earth – Jupiter : 32.7 min Earth – Saturn : 76.7 min
Earth – Pluto
: 5.5 hours Earth – Voyager1 : 13 hours
Earth – Voyager2 : 10.4 hours.
InterPlanetary Internet
Deep Space Network
InterPlaNetary Internet
Architecture



InterPlaNetary Backbone Network
InterPlaNetary External Network
PlaNetary Network
Architecture (contd …)

InterPlanetary Backbone Network
Links between Earth and other outer-space planets, moons,
satellites, relay stations, etc.

InterPlanetary External Network
Space crafts flying in groups in deep space between planets, clusters
of sensor nodes, and groups of space stations.

Planetary Satellite Network
Links between orbiting satellites & links between satellite and
surface elements.

Planetary Surface Network
Links between high power surface elements (landers, etc), Which
are usually organized in an ad hoc manner.
Why not current design?(2)

In the slow start algorithm, the congestion
window size (W) is increased by one packet per
received ACK until the slow start threshold
(Wss) is reached. This approach wastes the link
resources for a very long duration which is
proportional to the propagation delay. For Wss
= 20 and RTT = 20 minutes, it is shown that the
slow start algorithm cannot utilize the link
resources for approximately 120 minutes in deep
space links.
Why not current design? (3)

The inefficiency in link utilization due to window-based
mechanisms also exists during the congestion avoidance
phase, where the TCP source increments the
congestion window size by roughly one at each RTT.
The performance evaluation shows that window-based
TCP protocols achieve throughput of approximately 10
bytes/s for the link capacity of 1 Mb/s, packet loss
probability of p = 10-3 and RTT=40 minutes. In other
words, the entire deep space link remains almost
unutilized.
Related Works


Many transport protocols have been proposed for
satellite links, which are also characterized by high
bandwidth-delay products and high bit error rates.
However, the RTT values of these links are relatively
small (around 550ms). Moreover, packet losses due the
blackout conditions have not been studied.
Exist research on transport layer protocols for spacebased communication networks, like Space
Communications Protocol Standards-Transport
Protocol (SCPS-TP) by CCSDS is old (1997) and
inefficient.
TCP Planet (1)


TCP-Planet replaces the inefficient slow start
algorithms with a novel Initial State algorithm which
allows capturing link resources in a very fast and
controlled manner.
A new congestion detection and control mechanism,
which decouples congestion decision from single packet
loss, is developed to avoid the erroneous congestion
decisions due to high link errors.
TCP Planet (2)




TCP-Planet incorporates Blackout State procedure into
the protocol operation to reduce the effects of blackout
conditions on the throughput performance.
Bandwidth asymmetry problem is addressed by the
adoption of delayed SACK.
It runs on top of Internet Protocol (IP) layer and does
not require any specific modification to the lower layers
in the current TCP/IP protocol suite.
The structure of the protocol consists of two
Algorithms: Initial State and Steady State
TCP Planet (3)
Initial State Algorithm


It replaces the inefficient slow start algorithms
to capture link resources in a fast and controlled
manner.
The algorithm is composed of two main
procedures, i.e., Immediate Start (0 ≤ t ≤ RTT)
and Follow-Up (RTT ≤ t ≤ 2*RTT) .
Immediate Startup -- Emulated Slow Start



The first RTT is divided into equal intervals of size T.
The number of data packets transmitted in each T is
increased as in Slow Start algorithm of the classical
TCP protocols. This increase continues until the
emulated slow start threshold, ssthreshe, is reached .
Along with data packets, NIL segments encapsulated by
low priority IP packets is send to probe the link
resources. They are chosen from the unACKed packet
queue.
Immediate Startup
Immediate Startup -- Emulated Congestion
Avoidance


The Emulated Slow Start is left for Emulated
Congestion Avoidance phase when cwnd =
ssthreshe until the end of the RTT.
For further probing the link status, the source
keep cwnd constant and increase cwndN
additively by one NIL segment in each T interval
emulating congestion avoidance algorithm of
the classical TCP protocols.
Follow Up




During this phase, the feedback for the packets
transmitted in the Immediate Start phase are started
to be received by the TCP-Planet source.
Each received NIL segment indicates the existence
of unutilized link resources, so it counts the total
num (N) of packets received in one period T and
sends this information back as NIL ACK.
TCP-Planet source adjusts its transmission rate (S)
by using the information carried in NIL ACKs, S =
N/T , until the end of 2RTT.
Source starts sending NIX packets for congestion
monitoring
Steady State ( t ≥ 2RTT )

Four states in Steady State. A new congestion control
scheme is deployed to control the transitions between
these states. Therefore, the data transmission rate S can
be increased, decreased or hold.
Steady State – Congestion Control

NIX segments
 Low and high priority NIX segments of 40 bytes.
 No inform, only for congestion detection
 Sent at same rate as Data packets, so they experience
same packet loss rate due to space link errors.
 Low priority NIX get discarded first in case of a
congestion
 The only reason for low and high priority NIX
segments to have different packet loss rates is the
additional loss experienced by low priority segments
due to congestion.
Steady State – Congestion Control








Receiver counts number of received low (Nlow) and high
priority (Nhigh) NIX segments in a window of Tw
Received NIX are not acknowledged, only reception
statistics within a window Tw is send back by NIX ACKs
Let Φ = Nlow /Nhigh
Source infers that a congestion exists if Φ < 1.
Let Φd , Φi be preset rate decrease and increase thresholds
If Φ < Φd : Congestion is experienced. Source goes to
Decrease Rate state where S is decreased multiplicatively
If Φd ≤ Φ ≤ Φi : the rate S is kept unchanged.
If Φ > Φi : No congestion. S increases additively
Black Out





Blackout lead to burst packet losses & decrease in the
throughput.
If the source does not receive any type of ACK ( data
or NIX ) for a certain period Tw, it infers Blackout.
During Blackout, source keeps sending low and high
priority NIX segments.
Similar action is taken by the sink and it sends ZERO
NIX ACKs with (Nlow, Nhigh) as (0,0).
Since RTT is very high, the effect of blackout on
performance changes with it relative location. Assume
L is the duration of the blackout, and the blackout
occurs at a position x seconds away from the sink.
The Blackout State will improves the link utilization
for duration of L or 2x in the cases L < 2x and L 
2x.
Delayed SACK


If the data packets are 1KB, SACK packets are of 40B,
i.e. the ratio of the traffic in the forward and reverse
links is 25:1. However, the ratio in case of space links is
of 1000:1, and hence sending one SACK for each data
packet can cause congestion in the reverse link.
To avoid this problem, TCP-Planet deploys SACK
congestion control by delaying the SACKs. TCP-Planet
sink maintains delayed-SACK factor, d, and sends one
SACK for every d data packets received. If there is a
packet loss detected, then it sends a new SACK with an
updated block immediately.
The Licklider Transmission
Protocol



LTP is a retransmission protocol designed for
delay-tolerant reliable communication between
two points.
It serves as a convergence-layer protocol for the
interplanetary leg(s) of an end-to-end path in a
delay tolerant network.
LTP is principally aimed at supporting “long
haul” reliable transmission over deep-space RF
links.
Multiplicity of connections


Normal method of transmitting the additional data
blocks until all prior blocks are ACKed is unpractical.
Thus, any number of requested transmissions may be
concurrently "in flight" between two LTP engines; if
any of the data of a given block are lost at certain
transmission, the state of that transmission will be
retained and the retransmission cycles will begin.
A single TCP association (local host add/port, foreign
host add/port) can accommodate one connection at
one time. A single LTP association (local engine
ID/client service ID, foreign engine ID/client service
ID) can accommodate multiple concurrent
connections/sessions, one for each block of data in
transit on the association.
State Maintenance



The LTP engines must necessarily retain transmission
status and retransmission resources for all of the
sessions that might be set up.
These LTP transmission state information need to be
maintained for quite a long time since a long time may
pass before LTP can be assured of transmission success.
There may be a great deal of information that need to
be maintained.
Unlike TCP which typically retain transmission state in
DRAM, LTP will retain the state information in storage
like disk or flash memory. This will provide enough
space for data storage and prevent the data loss caused
by rebooting or power cycling of the computers.
Partial Reliability



Bandwidth utilization can be improved if part of a given
block of data is sent without acknowledgement and
possible retransmission. The idea is to get the necessary
data transmitted reliably but have the other data
transmitted unreliably.
For example, data contains a photograph: the first few
bytes might be important information without which the
photograph is useless, such as camera settings, while the
remainder describe fixed-length scan lines. Then, it is
important to assure delivery of the first few bytes, but the
loss of a few individual scan lines may not be important.
LTP regards each block of data as two parts: a "red-part",
whose delivery must be assured by acknowledgement and
retransmission, and a "green-part" whose delivery is
attempted but not assured..
Simplified Acknowledgment



Unlike TCP connections, LTP sessions are unidirectional.
Bidirectional data transfer is accomplished by opening two
individual LTP sessions.
LTP data acknowledgments - "reception reports" - are
carried in a separate segment type. Each report contains a
comprehensive report of all data received within some
specified range of offsets from the start of the transmitted
block.
These report segments are sent infrequently. The report
segments are normally sent only upon encountering the
“checkpoints" in the sequence of incoming data segments.
Checkpoints are inserted at the end of the red-part and at
the end of each retransmission.
Timeout Interval Computation



It is infeasible to use statistical analysis of round-trip
history as a means of predicting RTT. The RTT for
transmitted segment N could be much larger than segment
N-1 if there happened to be a loss of connectivity.
LTP calculate a first approximation of RTT by simply
doubling the known one-way light time to the destination
and adding an arbitrary margin for any additional
anticipated latency, such as queuing at both ends of the
transmission. For deep space operations, the margin value
is typically a small number compare to the RTT.
To account for the additional delay imposed by interrupted
connectivity, timers are dynamically suspend during periods
when the remote LTP engines are known to be unable to
transmit responses.
Network Layer Issues

Naming and Addressing
 What objects are named.
 Whether a name can be used directly by a data router
 The method by which the name/object binding are
managed
 DNS not suitable :
 If object on remote planet wants to resolve earth based
name it could query the DNS server on earth, but long
RTT would affect the performance
 It could maintain a secondary server locally, however
updates will dominate the communication channel
 It could have static name resolution, but that would not
allow scalability.
Network Layer Issues



Compatible with IPv4 and IPv6
Proposed Network Layer Protocol is ( SCPS-NP ),
Space Communication Protocol Standards – Network
Protocol.
Open Issues:
 Distribution of topology information.
 Path Calculation
 Interaction with transport layer protocols.
Comparison
Licklinder Protocol
TCP-Planet Protocol
Long Delay
Multiplicity of connections,
Modify the window-base design
in slow start and congestion
control. Introduce NIL/NIX pkts.
High Error
Rate
Partially reliability
Massive state retention.
Not partially issued
Blackout
Not partially issued, the
problem seems to be handed
to bundle layer.
Sender and sink keep sending
packets. Good for performance,
but waste resources.
Asymmetry Checkpoint
link
Delayed SACK
Routing
No routing
Handled by lower layer like IP.
Link
Support
assuming point-to-point, single
hop unidirectional Links
Used for multi-hop end-to-end
bidirectional links.
Evaluation
Good for store-and-send apps
like sensor network (e-mule)
Good for DTN with mobile nodes, but
the way to handle blackout still need
to be improved.
References









O.B. Akan, J. Fang, I.F. Akyildiz, TP-Planet: a reliable transport protocol for
InterPlaNetary Internet, IEEE Journal on Selected Areas in Communications.
O. B. Akan, J. Fang, I. F. Akyildiz, “Performance of TCP Protocols in Deep Space
Communication Networks,” IEEE Commun. Lett., November 2002.
I. F. Akyildiz, G. Morabito, S. Palazzo, “TCP-Peach: A New Congestion Control
Scheme for Satellite IP Networks,” IEEE/ACM Trans. Networking, June 2001.
D. T. Tran, F. J. Lawas-Grodek, R. P. Dimond, W. D. Ivancic, “SCPSTP, TCP and RateBased Protocol Evaluation for High-Delay, Error-Prone Links,” SpaceOps 2002.
E. Travis, “The Interplanetary Internet: Architecture and Key Technical Concepts,”
Internet Global Summit, INET 2001, June 5, 2001.
I. F. Akyildiz, O. B. Akan, C. Chen, J. Fang, andW. Su, “InterPlaNetary Internet: Stateof-the-art and research challenges ”
Burleigh et.al "The Licklider Transmission Protocol", draft-irtf-dtnrg-ltp-00.txt, May
2004
http://www.planetary.org/
http://deepspace.jpl.nasa.gov/dsn/
Thank you!