Study of Transport Layer Protocol for InterPlaNetary Internet

1. Study of Transport Layer Protocol for InterPlaNetary Internet Wenbin Ma

2. Contents • Introduction • IPN Architecture • Communication Suite • Challenges • Why not current design • Protocol: TCP Planet • Protocol: Licklider Transmission Protocol • Network Layer Issues • References

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

4. InterPlanetary InternetDeep Space Network

5. InterPlaNetary Internet Architecture • InterPlaNetary Backbone Network • InterPlaNetary External Network • PlaNetary Network

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

7. Communication Protocol Suite • Current Space / Ground protocol used by CCSDS (Consultative Committee for Space Data Systems ). • Each component of the IPN may have to run different set of protocols to suite the environment. • CCSDS protocol consists of 8 Layers • Used for the Mars Exploration mission communications.

8. CCSDS Protocol

9. CCSDS Protocol • Protocol Layers • Space Wireless Frequency and Modulation • Space Channel Coding • Space Link • Space Networking • Space end-to-end Security • Space end-to-end Reliability • Space File transfer • Space Application

10. CCSDS Protocol Limitation Although the current protocol is viable, there is a need to make the protocol stack adaptable to different environmental changes allowing integration of highly optimized regional network protocols. This leads to the proposed Protocol by Delay Tolerant Networking Research Group (DTNRG).

11. DTNRG Protocol Stack • The protocol replies on a middleware layer called bundle layer that resides between the application and the lower layers. • The bundle layer resolves the intermittent connectivity, long or variable delay, asymmetric data rates, high error rates by using a store and forward mechanism similar to email. • It uses per-hop error control which increases the probability of data transmissions.

12. DTNRG Protocol

13. Challenges • Long Delays: Communication links have long propagation delays due to the distance; also scheduling and queuing delays since the expensive special equipment is required and there may be many missions. • High Link Error Rates:Difficult to generate power on and around other planets, low signal-to-noise ratios and thus high error rates. Current deep-space missions operate with raw bit error rate on the order of 10-1. Extra coding can be used to reduce error rate but it will also reduce the available bandwidth.

14. Challenges (Contd.) • Blackouts: Periodic link outages may occur due to orbital obscuration with the loss of line-of-sight because of moving planetary bodies, the interference of an asteroid or a spacecraft. • Limited Bandwidth: maximum data rates on the order of a few tens of megabits per second will probably be the norm for the next few decades. • Asymmetry Data Rate: The asymmetry in the data rate of forward and reverse channels is typically on the order of 1000 : 1 in space missions.

15. Why not current design?(1) • TCP use the window-based mechanism during slow start and in the congestion avoidance algorithms, which will cause a high performance degradation. • The current TCP protocols are designed for wired links, which are assumed to have small bit error rates and always connected. High error rates mislead TCP to erroneous decrease of congestion window. • Even if TCP could be pushed to work, many applications either rely on several round of handshaking or have requirement of minimum RTT. For example, it typically takes 8 RTTs for FTP to start data transmission and the connection will be reset after 5 minutes of inactivity.

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

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

18. 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 space-based communication networks, like Space Communications Protocol Standards-Transport Protocol (SCPS-TP) by CCSDS is old (1997) and inefficient.

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

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

21. TCP Planet (3)

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

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

24. Immediate Startup

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

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

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

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

29. 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 Twis 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

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

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

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

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

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

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

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

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

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

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

40. Comparison

41. 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 Rate-Based 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: State-of-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/

42. Thank you!