Embed Size (px)
Citation preview
1
TCP-Planet: A Reliable Transport Protocol forInterPlaNetary InternetIan F. Akyildiz Ozgur B. Akan Jian Fang
Broadband & Wireless Networking LaboratorySchool of Electrical & Computer Engineering
Georgia Institute of Technology, Atlanta, GA 30332Tel: (404) 894-5141 Fax: (404) 894-7883Email:{akan,jfang,ian}@ece.gatech.edu
Abstract— The space exploration missions are crucial foracquisition of information about the space and the universe. Theentire success of a mission is directly related to the satisfactionof its communications needs. For this goal, the challenges posedby the InterPlaNetary Internet need to be addressed. CurrentTCP protocols have very poor performance in the InterPlaNetaryInternet which is characterized by extremely high propagationdelays, link errors, asymmetrical bandwidth and blackouts. Thewindow-based congestion control, which injects a new packetinto the network upon an ACK reception, is responsible for suchperformance degradation due to high propagation delay. Slowstart algorithms of the existing TCP protocols further contributeto the performance degradation by wasting long time periods toreach the actual data rate. Moreover, wireless link errors amplifythe problem by misleading the TCP source to unnecessarilythrottle the congestion window. The recovery from erroneouswindow decrease takes certain time, which is proportional tothe round-trip time (RTT) and further decreases the networkperformance.
In this paper, a reliable transport protocol, TCP-Planet, ispresented for data traffic in the InterPlaNetary Internet. It isintended to address the challenges and achieve high throughputperformance and reliable data transmission on deep space linksof the InterPlaNetary Internet. TCP-Planet deploys an end-to-endrate-based additive-increase multiplicative-decrease (AIMD) con-gestion control, whose AIMD parameters are tuned to help avoidthroughput degradation. TCP-Planet replaces the inefficient slowstart algorithms with a novel Initial State algorithm whichallows to capture link resources in a very fast and controlledmanner. A new congestion detection and control mechanism,which decouples congestion decision from single packet loss, isdeveloped to avoid the erroneous congestion decisions due tohigh link errors. In order to reduce the effects of blackoutconditions on the throughput performance, TCP-Planet incor-porates Blackout State procedure into the protocol operation.Bandwidth asymmetry problem is addressed by the adoption ofdelayed SACK. Simulation experiments show that TCP-Planetsignificantly improves the throughput performance and addressesthe challenges posed by the InterPlaNetary Internet.
Index Terms— Reliable Transport Protocol, InterPlaNetaryInternet, High Propagation Delay, Bandwidth Asymmetry, Black-outs.
I. INTRODUCTION
THE developments in the space technologies in the lastdecade have enabled the realization of deep space sci-
entific missions such as Mars exploration. These missions
produce significant amount of scientific data to be deliv-ered to the Earth. For successful transfer of scientific dataand reliable navigational communications, NASA enterpriseshave outlined significant challenges for development of next-generation space network architectures. The next generationdeep space networks are expected to provide communicationservices for scientific data delivery and navigation services forthe explorer spacecrafts and orbiters [6]. The next step in thedesign and development of deep space networks is expectedto be the Internet of the deep space planetary networks anddefined as InterPlaNetary (IPN) Internet [25].
A typical deep space network architecture shown in Fig.1 is proposed for the Mars Exploration mission [7]. Thearchitectural elements of the proposed infrastructure can besummarized as follows:
NetworkProximity
Earth
Planetary Satellite Network
Mars
Earth Relay Orbit
Interplanetary Backbone Network(Deep Space Communication Link)
Fig. 1. Deep space network architecture for the Mars Exploration mission.
• Interplanetary Backbone Network: It includes the di-rect link or multi-hop paths between the outer-space plan-ets and the Earth as well as the Earth-based infrastructureelements such as ground station for deep space network.
• Planetary Satellite Network: It consists of the satellitesorbiting the planets to provide communication relay andnavigation services to the surface elements.
• Planetary Proximity Network: It provides the commu-nication links between diverse range of surface elements,which are often spread out to form an ad-hoc network.
Among the above architectural elements of the InterPlaNe-tary Internet, we mainly focus on the Interplanetary BackboneNetwork where the source and sink end-points are basically
2
relay satellites orbiting around the planets. This is becausethe Interplanetary Backbone Network plays a significant rolefor the performance of entire deep space communication. Themost important characteristics and the challenges posed by theInterplanetary Backbone Network are listed as follows:
• Very long propagation delays: The deep space com-munication links may have extremely long propagationdelays. For example, the end-to-end round trip time forthe Mars-Earth communication network varies from 8.5minutes to 40 minutes according to the orbital locationof the planets [12].
• High link error rates: The bit error rates on the deepspace links are very high usually on the order of 10−1
[12].• Blackouts: Periodic link outages may occur due to orbital
obscuration with the loss of line-of-sight because ofmoving planetary bodies, the interference of an asteroidor a spacecraft [6].
• Bandwidth asymmetry: The asymmetry in the band-width capacity of forward and reverse channels is typ-ically on the order of 1000 : 1 in space missions [12].
These challenges need to be addressed in order to meet thecommunication requirements of deep space missions. How-ever, the existing TCP variants [16], [17], [13], [20], [8], [21],[9], [3] have been shown to achieve very poor performancein deep space communication networks [1]. The dominantfactor in this performance degradation is the extremely highpropagation delay in deep space links [1]. This is solelydue to the window-based mechanism used by the currentTCP protocols during slow start and congestion avoidancealgorithms. In the slow start algorithm, the congestion windowsize (W ) is increased by one packet per received ACK untilthe slow start threshold (Wss) is reached, i.e., W < Wss.However, this approach wastes the link resources for a verylong duration which is proportional to the propagation delay.For Wss = 20 and RTT = 20 minutes, it is shown in [1] thatthe slow start algorithm cannot utilize the link resources forapproximately 120 minutes in deep space links.
The inefficiency in link utilization due to window-basedmechanisms also exists during the congestion avoidance phase,i.e., W ≥ Wss, where the TCP source increments thecongestion window size by roughly one at each RTT. Theperformance evaluation study in [1] shows that window-basedTCP protocols achieve throughput of approximately 10 bytes/sfor the link capacity of 1 Mb/s, packet loss probability ofp = 10−3 and RTT = 40 minutes. In other words, the entiredeep space link remains almost unutilized during the entireconnection period. Note that RTT = 40 minutes is within theRTT range for communication links between Mars and Earth,i.e., 8.5 to 40 minutes based on the orbital position [12].
Furthermore, the current TCP protocols are designed forwired links, which are reasonably assumed to have negligiblebit error rates. Therefore, they invoke congestion control mech-anisms in case of a single packet loss. However, this assump-tion does not hold in deep space communication links. Conse-quently, the packet loss based congestion detection mechanismresults in unnecessary rate throttle and leads to severe through-
put degradation. Much research has been performed in recentyears in order to address the throughput degradation due towireless link errors [5]. However, these solutions cannot bedirectly applied to Interplanetary Backbone Network becauseof the amplifying effects of the extremely high propagationdelay and the other abovementioned characteristics on theproblem.
The TCP performance on the links with high bandwidth-delay products and errors is analyzed in [18]. Many transportprotocols [15], [2], [3] are proposed for satellite links, whichare also characterized by high bandwidth-delay products andhigh bit error rates. Nevertheless, these studies mostly refer toGeo-stationary Earth Orbit (GEO) satellite links with typicalRTT values around 550 ms, which are very low compared toRTTs in deep space communication links. Moreover, packetlosses due the blackout conditions may also mislead the con-gestion control mechanisms based on packet losses. In [14],an enhancement for TCP is developed to address signal lossconditions due to mobility. However, the blackout situations indeep space links are much more complicated due to extremelyhigh propagation delay and hence solutions as in [14] cannotbe applied directly.
There are more challenges which need to be addressed bythe new transport protocols in Interplanetary Backbone Net-work. These challenges are consequences of the characteristicsof the deep space links, and can be summarized as follows:
• Delayed Feedback: TCP is expected to respond to net-work state. This expectation creates problems in long-delay environments, since TCP uses end-to-end signalingfor its control loops. The higher RTT is experienced, theolder information about link conditions is received at thesource. Thus, the congestion control decision based onsuch past information might not lead to proper action.Therefore congestion control schemes, which react toinstantaneous packet loss situations, do not yield properresponse on the links with high propagation delay.
• Buffer Size: In order to assure 100% reliable transport,retransmission mechanism is inevitable. However, thisbrings considerable amount of memory requirement. Forexample, the transport protocol source should maintain1.2 GB buffer size for RTT = 20 minutes and theaverage data transmission rate of 1MB/s.
There already exists an active research on transportlayer protocols for space-based communication networks.Space Communications Protocol Standards-Transport Protocol(SCPS-TP) [11], [10] is a set of TCP extensions devel-oped by Consultative Committee for Space Data Systems(CCSDS) for space communications. SCPS-TP is designedto support current communication environments and those ofupcoming space missions [10]. SCPS-TP is developed basedon the existing TCP protocols with some modifications andextensions to address the challenges posed by space-basedsystems such as link errors, bandwidth asymmetry, and linkoutages. It can provide full, best-effort and minimal reliabilityaccording to the mission specific communication requirements.The capabilities of the SCPS-TP are basically a combination ofexisting TCP protocols, which are shown to be inadequate in
3
ImmediateStart Blackout
RateDecrease
RateIncrease
Hold Rate
Φ>φ i
Φ<φd
φ <Φ<φ idΦ<φd
Follow−Up
Φ>φ i φ <Φ<φ id
t=RTT
t= 2*RTTINITIAL STATE
STEADY STATE
Fig. 2. TCP-Planet protocol operation state diagram including substates and the state transitions based on congestion control decision mechanism.
addressing the challenges in Interplanetary Backbone Network[1]. For example, SCPS-TP with Vegas congestion controluses window-based scheme and adopts slow-start algorithm.Although the rate-based version of SCPS-TP is under develop-ment, it disables congestion control mechanism and performstransmission with user selected fixed rate [24]. On the otherhand, for example, SCPS-TP uses TCP-Vegas [8] congestiondecision mechanism based on the RTT variation. However,since the window-based nature of TCP-Vegas cannot fullyutilize the link, it is not even possible for it to experience thecongestion and hence variation in RTT. Therefore, congestiondecision based on RTT variation does not provide propercongestion control functionality. Furthermore, due to the ex-tremely high propagation delay, the variation in RTT maynot be measured accurately such that the resultant congestioncontrol behavior may also not be accurate.
As pointed out in [1], there exists an urgent need for reliabletransport protocol for InterPlaNetary Internet. In this paper,a reliable transport protocol, TCP-Planet, for InterPlaNetaryInternet (IPN) is presented. The objective of TCP-Planet isto achieve high throughput performance and reliable datatransmission by addressing the challenges in the IPN. In orderto address the challenges due to extremely high propagationdelay, TCP-Planet deploys a newly developed end-to-endrate-based additive-increase multiplicative-decrease (AIMD)congestion control, whose AIMD parameters are adjustedto compensate for the throughput degradation. Two novelalgorithms, i.e., Initial State and Steady State, constitute thestructure of the TCP-Planet protocol. Initial State algorithmreplaces the inefficient slow start algorithms in order to capturelink resources in a very fast and controlled manner. In SteadyState, a new congestion detection and control mechanism isdeployed to minimize the erroneous congestion decisions dueto high link errors. In order to reduce the effects of blackoutconditions on the throughput performance, TCP-Planet incor-porates Blackout State procedure into the protocol operation.Bandwidth asymmetry problem is addressed by the adoption ofdelayed SACK options. Performance evaluation via simulationexperiments reveals that TCP-Planet significantly achieveshigh throughput performance and addresses the challenges indeep space communication networks.
The remainder of the paper is organized as follows. TCP-Planet protocol overview along with the detailed operation ofthe Initial State algorithm is presented in Section II. In SectionIII, Steady State algorithm including the new rate-based AIMDcongestion control and Blackout State behavior are explained.Performance evaluation presented in Section IV is followedby the concluding remarks stated in Section V.
II. TCP-PLANET: INITIAL STATE
TCP-Planet source starts connection in the Initial State att = 0 by calling Initial State() algorithm as shownin Fig. 2. TCP-Planet source then goes to the Steady Stateby calling Steady State() algorithm at t = 2 · RTT asshown in Fig. 2.
The slow start algorithm used in the existing TCP proto-cols is shown to be inefficient on deep space links of theInterPlaNetary Internet [1]. In order to avoid performancedegradation due to Slow Start algorithm, TCP-Planet deploysInitial State() algorithm, which achieves to capturelink resources in a very fast and controlled manner. Thealgorithm is composed of two main procedures, i.e., ImmediateStart and Follow-Up.
A. Immediate Start
TCP-Planet starts a connection in the Immediate Start stateat t = 0, where the actual RTT is divided into time intervals ofsize T . TCP-Planet then emulates Slow Start and CongestionAvoidance algorithms of the conventional TCP protocols bytreating time intervals of size T as the RTT of the emulatedconnection. The objective of the Immediate Start phase is toprobe the network in a fast and controlled manner so thatthe transmission rate can be increased quickly according tothe feedback from the sink. The determination of the intervalsize T is presented in Section II-C. Here, we present theprotocol operation in the Immediate Start phase in two parts,i.e., Emulated Slow Start and Emulated Congestion Avoidance.
1) Emulated Slow Start: As shown in Fig. 3, the first RTTis divided into time intervals of size T . This is done in orderto have more fine-grained time unit than the extremely highRTT of the deep space link. The number of data packets
4
D D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
N
N
N
N
N
N
N D
D
N
N
N
N
N
N D
D
D
D N
N
N
N D
D
D
D
D
D
D
D
N N
N
D
D
D
D
D
D
D
D
N
N
N
N
N
N
N
N
N
N
D
D
D
D
D
D
D
D
N
N
N
N
N
N
N
N
ssthreshe
D Data Packet N NIL Segment
0 T 2T 3T 4T 5T
. . . . . . . .
RTTRTT−T
Emulated Congestion Avoidance
6T
IMMEDIATE START
Emulated Slow Start
Fig. 3. An example illustration of time framing mechanism in the Immediate Start phase for ssthreshe = 8.
transmitted in each interval, cwnd, is increased geometricallyin each interval as in Slow Start algorithm of the classical TCPprotocols. This increase continues until the emulated slow startthreshold, ssthreshe, is reached, i.e., cwnd ≤ ssthreshe.
In addition to data packets, NIL segments [3] are also sentin each time interval during the Immediate Start phase. Theobjective of NIL segment transmission is to probe actuallink resource status in the beginning of the connection. NILsegments are chosen from the unacknowledged outstandingdata packets to be used for packet loss recovery at the receiver.NIL segments are encapsulated by low priority IP packets.Note that the type of service (TOS) field of the IP packetheader can be used for this purpose. Hence, assuming therelay satellites serving as routers along the InterplanetaryBackbone link as shown in Fig. 1 have priority-queuingcapability, low priority NIL segments are discarded first in caseof congestion. Therefore NIL segment transmission does notaffect the throughput of the actual data packet transmission.If there is no congestion, they are received and ACKed backby the sink, which reveals that there are still unutilized linkresources along the path. NIL segments are created withGenerate Nil Segment() algorithm shown in Fig. 4,where Q is the length of the queue of unacknowledgedoutstanding data packets and i is a counter. Further detailsof the NIL segment generation can be found in [3].
In the Emulated Slow Start phase, the number (cwndN ) ofNIL segments transmitted in each interval is determined suchthat the total number of packets transmitted does not exceedthe emulated slow start threshold, i.e., cwnd + cwndN ≤ssthreshe.
In Fig. 3, we assume the emulated slow start threshold is8 packets, i.e., ssthreshe = 8. Therefore, the number of dataand NIL segments transmitted at each time interval during theEmulated Slow Start phase can be summarized as follows• 1st T cwnd = 1 and cwndN = 7.• 2nd T cwnd = 2 and cwndN = 6.• 3rd T cwnd = 4 and cwndN = 4.• 4th T cwnd = 8 and cwndN = 0.In general, the number of data packets and NIL segments
transmitted in the ith time interval during the Emulated Slow
Generate NIL Segment()Add unACKed packets into the queue;i = 0;if (NIL Segment is needed)q = i mod Q;i = i+ 1;NIL Segment = qth packet in queue;
end;if (jth packet in the queue is ACKed)
Remove the packet from Q;if (j < i and i > 0)i = i− 1;
end;end;if (New packet is added to Q)
Add the packet to the tail;Q = Q+ 1;
end;Return NIL Segment;
end;
Fig. 4. The NIL Segment Generating Algorithm
Start is given by
cwnd = 2i−1 (1)
cwndN = ssthreshe − 2i−1 (2)
2) Emulated Congestion Avoidance: The Emulated SlowStart is left for Emulated Congestion Avoidance phase whencwnd = ssthreshe. Since there is no feedback informationabout the link resources as yet, the TCP-Planet source does notincrease the number cwnd of data packets transmitted in eachtime interval. Therefore, cwnd = ssthreshe until the end ofthe emulated congestion avoidance phase. However, for furtherprobing the link status, the source increases cwndN additivelyby one NIL segment per T interval emulating congestionavoidance algorithm of the classical TCP protocols. As inFig. 3, during this phase cwnd is kept constant and cwndNis increased by one segment in each T until the end of theImmediate Start, when cwndN becomes equal to cwnd. Thetransmission of NIL segments is terminated at the end of thefirst RTT and TCP-Planet source goes to the Follow-Up state
5
of the Initial State algorithm as shown in Fig. 2.
B. The Follow-Up Phase
During this phase, the feedback for the packets transmittedin the Immediate Start phase are started to be received by theTCP-Planet source. In order to save scarce reverse channelresources of the bandwidth asymmetrical deep space link, thesink does not ACK back all the packets it receives . Severaldata packets are ACKed by a delayed SACK, whose details areexplained in Section III-D. Since NIL segments are transmittedto probe the link status, each received NIL segment indicatesthe existence of unutilized link resources. Hence, the TCP-Planet sink counts the total number (N ) of packets received inevery T period and sends this information back to the source.This information is carried in NIL ACKs. TCP-Planet sourcetransmits ssthreshe packets in RTT ≤ t ≤ RTT + T untilthe first NIL ACK received at t = RTT + T . Then, TCP-Planet source adjusts its transmission rate (S) by using theinformation carried in NIL ACKs, i.e., S = N/T , until theend of 2 ·RTT . Therefore, the transmission rate S at the endof the Initial State depends on the number of ACKs receivedin the last time interval of the Follow-Up phase.
Let NACK be the number of packets received by the TCP-Planet sink during RTT − T ≤ t ≤ RTT . Since the totalnumber of packets sent in the last interval of the ImmediateStart phase is 2 · sstreshe, the data transmission rate S at theend of the Initial State is expressed by
S =min{NACK , 2 · ssthreshe}
T(3)
In addition to the data packets, TCP-Planet source alsostarts sending NIX segments during the Follow-Up phase. TheNIX segments are much smaller than the data packets, i.e.,40 bytes. They are carried in both low and high priority IPpackets. During the Follow-Up phase, low and high priorityNIX segments are transmitted with the transmission rate SNixwhich is equal to the transmission rate of the data packets, i.e.,SNix = S. The objective of the NIX segment transmissionis to capture congestions and make decisions accordinglyin the Steady State. The details of the congestion detectionmechanism based on NIX segments are explained in SectionIII. The Follow-Up phase is over at t = 2·RTT and the sourceleaves Initial State for the Steady State as shown in Fig. 2.
Consequently, TCP-Planet source can capture the link re-sources as soon as t ≥ RTT+T based on the number of ACKsit receives from the sink. It can achieve this without leading tocongestion by controlling the number of probe packets injectedinto the network.
C. Determination of the Time Interval T
In the Initial State, the extremely high actual RTT isdivided into time intervals of size T and the conventional TCPbehavior is emulated to capture the available link resourcesin a controlled manner. The performance of the Initial Statedepends on the size of the T intervals. While the smaller Tincreases link utilization, it also increases overhead incurredby NIL segment transmission.
Initial State()Send connection request CONN REQUEST;Set T & ssthreshe by (8) & (9)n = 1;cwnd = 1;While (t ≤ RTT )/* Immediate Start */
While (cwnd ≤ ssthreshe)/* Emulated Slow Start */If ((n− 1)T ≤ t ≤ nT)Send (cwnd) DATA pkts;Send (ssthreshe − cwnd) NIL pkts;
end;n = n+ 1;cwnd = 2n−1;
end;/* Emulated Congestion Avoidance*/cwnd = ssthreshe;cwndN = 1;While ((n− 1)T ≤ t ≤ nT ≤ RTT)Send (cwnd) DATA pkts;Send (cwndN) NIL pkts;cwndN = cwndN + 1;n = n+ 1;
end;end;While (RTT ≤ t ≤ 2 ·RTT)/* Follow-Up */
If (NIL ACK RECEIVED)Set data rate S = N/T;Set NIX rate SNix = S;
end;end;Steady State();
end;
Fig. 5. The Initial State() algorithm
The objective of the Initial State is to reach a certain datatransmission rate, S, as soon as possible without leading to acongestion. During the Follow-Up phase, TCP-Planet sourceadjusts its transmission rate S according to the feedbackreceived from the sink every T period via NIL ACKs. Sincessthreshe is the maximum number of packets transmittedin one interval during the Emulated Slow Start phase, thetransmission rate reached in the Follow-Up phase is dependenton ssthreshe. Here, we assume that TCP-Planet source has agiven target minimum transmission rate requirement, B. Thisrequirement can be mostly due to two main reasons:• Application: The minimum transmission rate is required
in order to meet specific application needs such astransmission of scientific multimedia data which requires100% reliability and a minimum bound on the transmis-sion rate.
• Latency: The maximum allowed latency can be adver-tised by the specific space mission requirements as themaximum duration for the transmission of certain amountof data. This determines the minimum target transmissionrate requirement for a given connection.
Consequently, in order to achieve the target transmissionrate of B packets/s at t = RTT + T , the correspondingsshtreshe is calculated as
ssthreshe = B · T (4)
6
The Emulated Slow Start phase of the Immediate Start ter-minates when the number of data packets transmitted in onetime interval reaches the emulated slow start threshold, i.e.,cwnd = ssthreshe. Therefore, from (2) it follows that theduration of the Emulated Slow Start phase (Tess) is given by
Tess = (log2 ssthreshe + 1) · T (5)
During the Emulated Congestion Avoidance phase, thenumber of data packets per interval, cwnd, is kept constant.Moreover, the number of NIL segments is increased by one perinterval until the end of the Immediate Start, i.e., t = RTT .In order to probe the network resources in the range of[B, 2B], the source increases the number of NIL segmentstransmitted in each interval until it is equal to the numberof data packets, i.e., cwndN = ssthreshe. The ImmediateStart is over once cwndN reaches ssthreshe at t = RTT .Therefore, the duration of the Emulated Congestion Avoidancephase (Teca) can be expressed by
Teca = ssthreshe · T (6)
Since the total duration of the Immediate Start is Tess+Teca =RTT , from (5) and (6) it follows that
(log2 ssthreshe + 1 + ssthreshe) · T = RTT (7)
As (log2 ssthreshe + 1) is negligible compared tossthreshe itself, from (4) and (7) the size of the time intervalT can be calculated by
T =
√RTT
B, (8)
where B is the target transmission rate in packets/s. At thebeginning of a connection, RTT is also not known to the TCP-Planet source. Therefore, TCP-Planet source also caches theRTT of the past connections and uses that value in order tocalculate the time interval size T by (8) during the Initial State.
Consequently, the emulated slow start threshold can beexpressed by using (4) and (8) as follows
ssthreshe =√RTT ·B (9)
Thus, at the beginning of the connection, T and ssthresheare set by (8) and (9). The first RTT period is then dividedinto time intervals of size T . The Emulated Slow Start andEmulated Congestion Avoidance phases are performed in thefirst RTT in order to perform resource probing. In the secondRTT, the transmission rate is increased by sending a new datapacket for each received ACK until t = 2 · RTT . By thisway, TCP-Planet source can increase its transmission rate veryquickly and efficiently utilize the resources during the InitialState without leading to any congestion.
D. The Connection Establishment
The conventional TCP protocols perform three-way hand-shake for connection establishment. The existing protocolssend connection request segment at the beginning of theconnection and do not transmit any data segments until theconnection ACK is received from the receiver. This approachresults in waste of huge bandwidth for at least a duration
of one RTT in deep space links. In order to avoid thisinefficiency, TCP-Planet source does not wait for the ACKfor the connection request and starts data transmission in theInitial State as if the session request is granted. If the requestis rejected, then the connection is terminated after one RTT .
As a result, TCP-Planet achieves better utilization of linkresources in the early phases of the connection by the InitialState algorithm. The overall Initial State algorithm of the TCP-Planet is summarized in Fig. 5.
III. TCP-PLANET: STEADY STATE
TCP-Planet source leaves Initial State for Steady State at t =2 ·RTT and remains in the Steady State until the connectionis terminated. During the Steady State operation, TCP-Planetsource can be in one of the four states, i.e., Increase Rate,Decrease Rate, Hold Rate and Blackout as shown in Fig. 2.In the beginning of the Steady State, the source goes to HoldRate state, where no transmission rate change is performed.During Steady State operation, TCP-Planet deploys a newcongestion control scheme. Hence the transitions betweenthese states in the Steady State is decided based on thiscongestion control scheme. Therefore, the data transmissionrate S can be increased, decreased or hold according to thecurrent state.
A. Congestion Control
TCP-Planet deploys a new congestion control scheme inorder to address the challenges due to high link error ratesin Interplanetary Backbone Network. The objective of thismethod is to decouple network congestions and packet lossesdue to errors.
During the Steady State, TCP-Planet source transmits lowand high priority NIX segments continuously for congestiondetection purposes. NIX segments are carried by IP packets,which are marked as high and low priority using TOS field inthe IP packet header. NIX segments differ from NIL segmentsused in Initial State in terms of their size and functionality.Unlike NIL, NIX segments are much smaller compared to datasegments, i.e., 40 bytes. They do not carry any information andthus, cannot be used for error recovery purposes.
Low and high priority NIX segments are transmitted si-multaneously with the same rate (SNix) equal to the datatransmission rate (S), i.e., SNix = S. The objective of this isto obtain congestion decision support via comparison betweenthe reception statistics of both low and high priority NIXsegments. Since low and high priority NIX segments are equalin size and are transmitted with the same rate SNix, theyexperience the same packet loss rate due to space link errors.However, assuming the relay satellites serving as routers alongthe Interplanetary Backbone link as shown in Fig. 1 havepriority-queuing capability, low priority NIX segments arediscarded first in case of a congestion. The only reason forlow and high priority NIX segments to have different packetloss rates is the additional loss experienced by low prioritysegments due to congestion. This reasoning constitutes thebasis for our congestion detection method via NIX segmenttransmission.
7
TCP-Planet sink counts the number of received low (NLow)and high (NHigh) priority NIX segments in a sliding timewindow of Tw. The received NIX segments are not ACKedback to the sender. Note that this also avoids an overheadin the reverse channel, which can also become a bottleneckdue to bandwidth asymmetry in deep space links. Only thereception statistics within a time window of Tw are returnedto the sender every τ period. This information is carried byNIX ACKs. TCP-Planet source receives NIX ACKs carrying(NLow, NHigh) at the end of each measurement period τ .
Let Φ be the ratio of the number of received low and highpriority NIX segments, i.e.,
Φ =NLowNHigh
(10)
Assuming that the low and high priority NIX packets expe-rience same packet loss rate due to the link errors within ameasurement period τ , since the only reason for NLow <NHigh is the congestion along the path, TCP-Planet sourceinfers that a congestion exists if Φ < 1.
The entire congestion control of the TCP-Planet sourceis determined according to the value of Φ. The transitionsbetween Increase, Decrease and Hold Rate states in Fig. 2are performed based on Φ. In order to avoid unnecessarystate transitions, decision is made via comparison of Φ withpreset rate decrease, φd, and the rate increase thresholds, φi,as shown in Fig. 2. These thresholds are protocol parameters,whose selection is an implementation issue. The values ofφd and φi, which yield highest protocol performance, aredetermined during simulation experiments and are given inSection IV.
The summary of the congestion control mechanism is givenas follows:
1) Φ < φd: In this case, TCP-Planet source infers that con-gestion is experienced along the path. Thus, the sourcegoes to the Decrease Rate state where the transmissionrate S is decreased multiplicatively, i.e., S = S · ζ.
2) φd ≤ Φ ≤ φi: In this case, the data transmission rate Sis kept unchanged until next feedback is received fromthe sink.
3) Φ > φi: TCP-Planet source infers that no congestion isexperienced. Consequently, it increases the data trans-mission rate additively, i.e., S = S + δ.
The additive-increase (δ) and multiplicative-decrease (ζ)parameters are used to perform AIMD rate control every τperiod. The selection of these AIMD parameters are explainedin Section III-B. The steps of the Steady State algorithm ofTCP-Planet protocol is summarized in Fig. 6.
B. The New Rate-Based AIMD Scheme
As mentioned before, current TCP protocols achieve verypoor performance on the links with extremely high propaga-tion delay mostly due to their window-based operation [1].The throughput of the window-based TCP protocols and rate-based schemes are inversely proportional to the RTT [22]and the square-root of RTT (see the Appendix), respectively.Thus, the rate-based congestion control schemes are more
Steady State()Set ξ;Set α by (12);Set ζ & δ by (13) & (14);Send DATA pkts with rate S;Send Low pri. NIX pkts with rate S;Send High pri. NIX pkts with rate S;If (NIX ACK RECEIVED)Congestion Decision:
If (Φ < φd)/* Decrease Rate */S = S · ζ;
else if (φd ≤ Φ ≤ φi)/* Hold Rate */S = S;
else if (Φ > φi)/* Increase Rate */S = S + δ;
end;end;If (ZERO NIX ACK RECEIVED)
/* After Blackout State */Goto Hold State;
end;If (NO ACK in Tw)
/* Blackout State */Send Low pri. NIX pkts with rate S;Send High pri. NIX pkts with rate S;Retransmit TIMEOUT pkts;If (NIX ACK RECEIVED)If (ZERO NIX ACK)/* L ≥ 2x */Goto Hold State;
else/* L < 2x */Goto Congestion Decision;
end;If (DATA ACK RECEIVED)/* L < 2x */Goto Congestion Decision;
end;end;
end;
Fig. 6. The Steady State() algorithm.
robust to excessive propagation delays than the window-based mechanisms. Hence, in order to address the adverseeffects of extremely high propagation delay on the through-put performance, TCP-Planet deploys rate-based additive-increase multiplicative-decrease (AIMD) congestion control.The steady state throughput of the rate-based AIMD schemeis derived in the Appendix and expressed by
T =α
4 · (1− ξ)
[1 + ξ +
√(3− ξ)2 +
8 · (1− ξ2)
α ·RTT · p
](11)
where α and ξ are the additive-increase and the multiplicative-decrease factors, respectively and p is the packet loss prob-ability. It is observed from (11) that the throughput of therate-based AIMD scheme depends on the values of α andξ. Therefore, TCP-Planet adapts its AIMD parameters to thelink conditions, i.e., RTT and packet loss rate, such that theiradverse effect on the performance are compensated and a giventarget throughput is achieved.
8
The additive-increase parameter (α) of the rate-based AIMDscheme to achieve a target throughput of B packets/s can beobtained from (11) as follows
α = (1+ξ)2
(B + 1
RTT ·p
)[√1 + 8B2(1−ξ)
(B+ 1RTT ·p )
2(1+ξ)2
− 1
](12)
where ξ is the multiplicative-decrease factor and p is the packetloss probability, respectively. Here, the target throughput Bcan be defined as the average data rate required to transmitcertain amount of information within the certain delay boundas in Section II-C.
These AIMD parameters, α and ξ, in (12) are the ratechange parameters to be used to control the rate with periodRTT. However, TCP-Planet source performs rate control withthe feedback received from the sink every τ period, whereτ � RTT . Thus, the rate control parameters α and ξ in(12) cannot be directly used for TCP-Planet. These parameters,instead, represent the upper bound for the rate change of theTCP-Planet source within one RTT period. Hence, the AIMDparameters to be used by the source with period τ can bederived from α and ξ.
Let τ be the NIX segment reception statistics feedbackperiod. Thus, TCP-Planet source performs at most RTT/τnumber of rate changes within one RTT period.
Let δ and ζ be additive-increase and multiplicative-decreaseparameters to be used by TCP-Planet for rate control withperiod τ . Then ζ can be calculated as
ζ = ξ(τ/RTT ) (13)
By the same reasoning, the additive increase factor to be usedby TCP-Planet source can also be calculated as
δ =α · τRTT
(14)
TCP-Planet source uses AIMD scheme during the SteadyState operation as shown in Fig. 2. At the end of the InitialState, i.e., t = 2 · RTT , it calculates the packet loss rate pby using the number of transmitted and ACKed data packetsand NIL segments. TCP-Planet source then uses (12), (13)and (14) to calculate its AIMD parameters, i.e., ζ, δ. Con-sequently, according to the result of the congestion decisionmechanism presented in Section III-A, the transmission rateS is multiplicatively decreased or additively increased with ζand δ, respectively.
C. The Blackout State Behavior
Link outages due to loss of line-of-sight by orbital ob-scurations lead to burst packet losses and decrease in thethroughput. In order to provide reliable transport, SACKoptions [20] are adopted by TCP-Planet to address burst losses.Due to possible inadequacy of the number of SACK blocksin the SACK option field for very long blackout durations,timeout mechanism is also included in TCP-Planet. In orderto reduce the throughput loss due to blackouts, Blackout Stateis developed and incorporated into the Steady State.
TCP-Planet source receives data ACKs for reliability controlpurposes and NIX ACKs for NIX segment reception statistics.If the source does not receive any type of ACK for a certain
period of time Tw, it infers this condition as blackout andgoes to the Blackout State as shown in Fig. 2. The objectiveof the Blackout State procedure is to reduce the throughputdegradation due to the blackout situation.
During blackout, TCP-Planet source keeps sending low andhigh priority NIX packets without changing its transmissionrate. The same blackout event is also detected by the TCP-Planet sink if no packet is received within Tw period. Althoughthe sink does not receive any low and high priority NIXpackets during the blackout, it keeps sending NIX ACKs with(NLow, NHigh) as (0,0). These ACK packets are called ZeroNIX ACKs. The objective of Zero NIX ACKs is to help TCP-Planet source to capture accurate information regarding theblackout situation and act accordingly.
Since RTT is very high, the effect of blackout on theperformance changes with its relative location of blackoutoccurrence with respect to the sink. Let t = t0 be the timewhen blackout occurs and L is the duration of the blackout.Assume that the blackout occurs at a position x seconds awayfrom the TCP-Planet sink. For rtt = RTT/2, there are twodistinct cases according to the duration of the blackout and itsrelative distance to the TCP-Planet sink in time:
1) L < 2x: After rtt−x from t0, i.e., at t1 = t0 + rtt−x,TCP-Planet source detects the period without ACKs. Ifthe duration of the period with no ACK takes more thanTw, then the source moves to Blackout State at t = t1,as in Fig. 7.
t 0 t 1
(rtt−x)
t 2
Normal ACKsstate=(Increase,Decrease, Hold)
t 3
L
Normal ACKsstate=(Increase,Decrease, Hold)
t 4
L
No ACKsstate=Blackout
Source Sink
Zero NIX ACKsstate=Hold
t
(2x−L)
Fig. 7. Blackout condition observed from TCP-Planet source for L < 2x.
In this case, TCP-Planet source does not send any newdata packets but sends low and high priority NIX seg-ments without changing their transmission rate. It alsodoes not invoke congestion control mechanism. It startsretransmission of the packets whose retransmission timeris expired. At t2 = t1 + L, TCP-Planet source receivesnormal ACKs for duration of 2x− L. Therefore, TCP-Planet source infers that blackout is over and goes toany of the Increase, Decrease and Hold states accordingto the information it receives in the first NIX ACK asshown in Fig. 2. At t3 = t2 + 2x− L, the source startsto receive Zero NIX ACKs for duration of L. TheseZero NIX ACKs, are in fact, transmitted by the receiverwhen it detects the same blackout condition. Therefore,TCP-Planet does not go to Blackout State instead it goesto Hold State, where it keeps sending new data packetswith the same transmission rate again as shown in Fig. 2.Consequently, TCP-Planet reduces the effect of blackouton the performance by not wasting the link resources fora duration of L.
2) L ≥ 2x: In this case, TCP-Planet source detects no ACKperiod and goes to Blackout State at t1 = t0 + rtt− x
9
Source Sink
t
2x
No ACKsstate=Blackout
L
t 0 t 1
(rtt−x)
Normal ACKsstate=(Increase,Decrease, Hold)
t 3
Zero NIX ACKsstate=Hold
t 2
Fig. 8. Blackout condition observed from TCP-Planet source for L ≥ 2x.
for the blackout which occurred at t = t0. It again doesnot change its transmission rate and does not send anynew data packet. At t2 = t1 + L, the source starts toreceive zero NIX ACKs for duration 2x as shown inFig. 8. This reveals that the blackout is over for TCP-Planet source and then the source leaves Blackout Statefor Hold State as shown in Fig. 2. It stays in HoldState and keeps sending data packets with the sametransmission rate before the blackout was detected. Att3 = t2 + 2x, Zero NIX ACKs period is over andaccording to the information received in the first NIXACK the source performs state transition. Hence, theduration of 2x is efficiently utilized by the help of ZeroNIX ACK mechanism.
Consequently, the Blackout State reduces the throughputdegradation due to blackout conditions and improves the linkutilization for duration of L or 2x in the cases L < 2x andL ≥ 2x, respectively.
D. The Delayed SACK
TCP-Planet uses selective acknowledgement (SACK) [20]options for assurance of reliable data segment transmission.TCP-Planet sink continuously sends SACK back to the sourcefor each data packet it receives. Given that the data packets are1KB and SACKs are 40B, then the ratio of the traffic in theforward and reverse channels is 25:1, i.e., 1KB/40B. Thus, thebandwidth asymmetry up to 25:1 cause no congestion in thereverse link. However, the bandwidth asymmetry in the spacelinks is usually on the order of 1000:1 [12]. Thus, sending oneSACK for each data packet can cause reverse channel to becongested resulting in packet losses in the reverse link.
In order to avoid this problem, TCP-Planet deploys SACKcongestion control by delaying the SACKs. TCP-Planet sinkmaintains delayed-SACK factor, d, and sends one SACK forevery d data packets received. If there is no packet lossand hence no change in the SACK blocks, then TCP-Planetsink keeps delaying SACKs with a delayed-SACK factor ofd. Otherwise, it sends a new SACK with an updated blockimmediately. Therefore, the amount of traffic on the reversechannel is controlled by adjusting the delayed-SACK factord. Effects of the blackout on throughput and the improvementachieved by delayed-SACK is evaluated in Section IV-D.
IV. PERFORMANCE EVALUATION
In order to investigate the performance of the TCP-Planet,we conducted extensive simulation experiments. The im-provement in the initial phase of the connection achievedby the Initial State algorithm is evaluated in Section IV-A. Throughput performance of TCP-Planet is analyzed in
0
20
40
60
80
100
120
140
160
180
200
0 200 400 600 800 1000 1200
Dat
a R
ate
(pac
kets
/s)
Time (s)
Initial State
Fig. 9. Transmission rate change in the Initial State of TCP-Planet sourcefor RTT = 600 seconds.
Section IV-B along with the overhead introduced. Effects ofblackout conditions on the performance and the performanceof TCP-Planet with the improvement by Blackout State areinvestigated in IV-D. TCP-Planet performance on deep spacelinks with asymmetrical bandwidth and the improvement withdelayed SACK are explored in Section IV-E.
A. Initial State Performance
In order to avoid performance degradation due to in-efficient connection starting behavior, TCP-Planet deploysInitial State() algorithm in Fig. 2 and Fig. 5. Here, wesimulate a topology where the source and sink are connectedthrough a deep space link with RTT = 600 seconds andp = 10−5. We perform same experiment with TCP-Planet,TCP-Peach+ [3] and TCP-NewReno. The reason is that mostof the current TCP protocols deploy initial phase behaviorbased on the Slow Start algorithm, which is also used by TCP-NewReno.
In Fig. 9, the transmission rate change in the Initial Stateof TCP-Planet source is plotted, where the target transmissionrate of TCP-Planet source is assumed to be 100 packets/s. Be-cause of the very high propagation delay and 100% reliabilityrequirement, the amount of buffer required for retransmissionmechanism is proportional to the data transmission rate. There-fore, for very high data rates, this brings considerable amountof memory requirement. For example, the source needs tomaintain 0.6 GB of buffer for RTT = 10 minutes and theaverage data transmission rate of 1MB/s. Thus, we set targetdata rate to 100 packets/s in order to maintain practicality interms of memory requirements.
As explained before, TCP-Planet source performs EmulatedSlow Start phase, which ends once the number of data packetstransmitted in one time interval is equal to ssthreshe. Asseen in Fig. 9, the Emulated Slow Start phase lasts forapproximately Tess = 19.58 seconds and the TCP-Planetsource reaches 100 packets/s data rate by then. EmulatedCongestion Avoidance phase then starts and lasts until theend of the first RTT of the connection period. During this
10
0
5
10
15
20
25
0 500 1000 1500 2000 2500 3000 3500
Cong
estio
n W
indow
(pac
kets)
Time (s)
Jump Start
0
2
4
6
8
10
12
14
16
18
20
22
0 500 1000 1500 2000 2500 3000 3500
Cong
estio
n W
indow
(pac
kets)
Time (s)
Slow Start
Fig. 10. Congestion window size change during Jump Start algorithm ofTCP-Peach+and Slow Start algorithm of TCP-NewReno and for RTT = 600seconds.
0
10
20
30
40
50
60
70
80
90
0.1 1 10 100
Thr
ough
put (
pack
ets/
s)
File Size (MB)
p=10^{-5} p=10^{-4} p=10^{-3}
Fig. 11. Throughput for changing p and file size with RTT = 600 seconds.
phase, the data transmission rate is not increased instead NILsegment transmission rate is increased linearly to further probethe link resources. At t ≈ 600, the source goes to Follow-Up period and increases its transmission rate based on thefeedback received from the sink every T period. At t = 1200seconds, the transmission rate reaches 200 packets/s.
TCP-Peach+ [3] deploys Jump Start algorithm in order tocapture link resources very quickly. In Jump Start, the sendersets the congestion window, cwnd, to 1. After sending the firstdata segment, it transmits NIL segments every RTT/rwnd,where rwnd is the receiver window size. As a result, afterone round trip time, the congestion window size increasesvery quickly as the ACKs for NIL segments arrive at thesender. The performance of Jump Start is shown in Fig. 10.The congestion window of TCP-Peach+ reaches 20 packets
TABLE I
PROTOCOL PARAMETERS USED IN EXPERIMENTS
Parameter Value Definitionφi 0.8 Rate increase thresholdφd 0.2 Rate decrease thresholdτ 5 NIX ACK period in secondsTw 20 Sliding window size in secondsξ 0.5 Rate decrease parameter for RTTd 5 Delayed-SACK factor in number of packets
in at most 2 · RTT duration. It is, however, still very lowcompared to the performance of Initial State of TCP-Planet,which reaches 200 packets/s data rate at the end of 2 ·RTT .
The slow start performance is, however, not even closeto what Initial State of TCP-Planet achieves in deep spacelinks of the IPN. In Fig. 10, the congestion window evolutiondependent on time is shown during the slow start. The slowstart period lasts for approximately 6 · RTT for thresholdwindow size of 20 packets. Therefore, the link is not efficientlyutilized for 60 minutes due to unsuitability of the slow startalgorithm to extremely high propagation delays in deep spacelinks.
B. Throughput Performance
In order to show the throughput performance of TCP-Planet in deep space links, we perform several experimentsby varying packet loss probability p and the size of the datato be transmitted. We assume 1Mb/s as the capacity of thelink and RTT = 600 seconds. The target transmission rateB is set to be 100 packets/s, i.e., 100 KB/s for data packetsof size 1KB. The protocol parameters given in Table I areused during simulation experiments unless otherwise stated.The investigation of the effects of these parameters on theprotocol performance are left for future study.
In [1], existing TCP protocols including TCP-Vegas, whichis adopted by SCPS-TP protocol as a congestion controlscheme for space-based communications [10], have beenshown to achieve very poor performance in deep space links.For RTT = 600 seconds and p = 10−3, the throughputachieved by TCP protocols is approximately around 30 B/sand hence almost the entire link remains almost unutilized [1].Although TCP-Peach+ has significantly outperformed otherTCP schemes for the same link, the performance degradationwas yet too serious that it could achieve throughput around93 B/s. Thus, the same experiments are not repeated here andthe details can be found in [1].
TCP-Planet simulation experiments are performed for trans-mission of varying file sizes between 100KB and 200MBand for varying packet loss probability p of 10−5, 10−4,10−3. As shown in Fig. 11, the throughput increases withincreasing file size. This is because the larger the file size is thelonger TCP-Planet stays in the Steady State. As a result, thelink utilization is increased. Although throughput decreasesfor increasing packet loss probability, this degradation alsodecreases for increasing file size. This is mostly becausethroughput improvement by new congestion control schemeis higher when the protocol stays in Steady State for longer.
11
0
20
40
60
80
100
120
150 200 250 300 350 400 450 500 550 600
Thr
ough
put (
pack
ets/
s)
RTT(s)
Fig. 12. Throughput for changing RTT for file size of 50MB and p = 10−5.
For transmission of 200MB and p = 10−5, TCP-Planetthroughput increases up to 82.2 packets/s approaching itstarget throughput value, i.e., B = 100 packets/s. Hence, TCP-Planet outperforms existing TCP protocols by approximately103 times in terms of throughput.
In Fig. 12, the effect of RTT on the throughput performanceis shown. The experiments are performed for the transmissionof a 50MB file. The increase in RTT leads to throughputdegradation as shown in Fig. 12. However, the throughputdegradation due to high propagation delay is not as severeas it is for conventional TCP protocols [1]. This is because ofthe new rate-based congestion control scheme used in SteadyState of the TCP-Planet. At RTT = 600 seconds, TCP-Planet achieves 44.72 KB/s throughput. Note that this valuecan further increase with increasing file size as in Fig. 11.
C. Overhead
During the connection period, TCP-Planet source bringsoverhead to the deep space link. This overhead is due to NILsegment transmission to probe the link resource in the InitialState and low and high priority NIX packets transmissionfor congestion decision support in the Steady State. In thissubsection, we investigate the overhead caused by the injectionof NIL and NIX segments into the network.
In Fig. 13, the overhead incurred by TCP-Planet is shownfor transmission of files with varying sizes and for differentpacket loss rates, i.e., p = 10−5, 10−4, 10−3. For very smallfiles, i.e., < 10MB the overhead is relatively high. Because,in this case, significant portion of the connection period isspent in the Initial State, where the number of NIL segmentstransmitted is high compared to that of data packets. As thefile size increases, the overhead decreases as in Fig. 13. Thisis because the overhead in the Steady State is due to thetransmission of small sized (40 bytes) NIX segments andhence is much lower compared to Initial State. Therefore, asthe file size increases, the time spent in Steady State alsoincreases, which in turn decreases the overall overhead inthe connection period. As a matter of fact, the scientific datadelivered during space exploration missions are significantly
0
10
20
30
40
50
60
70
80
90
100
0.1 1 10 100 1000
Ove
rhea
d (%
)
File Size (MB)
p=10^{-3} p=10^{-4} p=10^{-5}
Fig. 13. Overhead due to transmission of NIL and NIX segments for changingfile size and p with RTT = 600 seconds.
high [6], i.e., in the order of gigabytes, which leads to verylow overhead.
On the other hand, the overhead does not significantlyvary for different p. As a matter of fact, the amount ofNIL segments transmitted in the Initial State depends onlyon the target throughput and the RTT and thus it is notdependent on p. This overhead exists only in the beginningof the connection. Although the NIL segment transmissionduring Initial State brings overhead, it also leads to significantperformance improvement as observed in Section IV-A. Asthe NIX transmission rate is equal to data rate and thecongestion control is robust to link errors, the overhead dueto NIX transmission is also independent of p. The overheaddue to NIX transmission exists after the Initial State untilthe end of the connection. However, the congestion controldecision support provided by NIX segments lead to significantthroughput performance improvement. For 1GB file size andp = 10−3, the overhead becomes as low as 8.1 %, which isquite low compared to throughput improvement with a factormore than 103.
D. Blackout Conditions
When a blackout is detected, TCP-Planet moves to BlackoutState as shown in Fig. 2 in order to reduce its effect onthe throughput performance as explained in Section III-C.Throughput achieved by TCP-Planet for different blackoutdurations is given in Fig. 14. Here, RTT = 120 seconds,p = 10−5 and the target data rate is assumed to be 50 KB/s.The simulations are performed for a duration of 600 seconds,where the blackout occurs at t = 250 seconds.
As in Fig. 14, throughput decreases with increasing blackoutduration as expected. This decrease is observed in both of thecurves representing the TCP-Planet operation with and withoutBlackout State procedure. However, Blackout State procedureimproves the performance for long blackout durations. Foreven a blackout of 150 seconds, which is 1/4 of the entire sim-ulation time, TCP-Planet achieves 36.41 packets/s throughputwith the help of Blackout State behavior. This corresponds to
12
30
35
40
45
50
55
60
0 20 40 60 80 100 120 140
Thr
ough
put (
pack
ets/
s)
Blackout Duration (s)
w/ Blackout State w/o Blackout State
Fig. 14. Throughput for changing blackout duration with RTT = 120seconds and p = 10−5 .
0
10
20
30
40
50
60
5 10 15 20 25 30 35 40
Thr
ough
put (
pack
ets/
s)
Delayed-SACK Factor (d)
100:1 1000:1
Fig. 15. Throughput for changing delayed SACK factor d with RTT = 120seconds and p = 10−4.
approximately 14% performance improvement over the casewithout Blackout procedure.
E. Bandwidth Asymmetry
In order to address bandwidth asymmetry problems, TCP-Planet delays SACKs with a certain delayed SACK factor.Simulation experiments are performed to show the effect ofbandwidth asymmetry on the performance and the improve-ment achieved by delayed SACK. Here, RTT = 120 secondsp = 10−4 and the simulation time is assumed to be 1200seconds. The target rate is set to 50 KB/s. In Fig. 15, two caseswith different bandwidth asymmetry ratio are investigated:
1) 100:1. In this case, forward and reverse link capacitiesare 100 KB/s and 1 KB/s, respectively. Since the ratio ofthe size of data packets and SACK packets is 25:1, theactual asymmetry ratio is 4:1 in this case. Therefore, thethroughput is not significantly degraded by asymmetricalchannel capacity of the deep space link. As shownin Fig. 15, an increase in the delayed SACK factoralso leads to an increase in the throughput. However,
throughput decreases for both cases with either too highor too small delayed SACK factor of d. This is becauseif it is too small, reverse channel is congested. Onthe other hand, if d is too large, the source receivesless number of SACKs than it expects which leads toperformance degradation. Thus, at d = 15, throughputachieved increases up to 52.02 packets/s.
2) 1000:1. In this experiment, bandwidth asymmetry onthe order of 1000:1 is simulated by setting forwardand reverse link capacities to 100 KB/s and 0.1 KB/s,respectively. Thus, the throughput is dramatically af-fected by the bandwidth asymmetry in this case, wherethe actual bandwidth asymmetry is 40:1. Therefore,throughput improvement with delayed SACK method ismore significant for higher bandwidth asymmetry. Forthe case without delayed SACK, throughput decreasesto up to 1.99 KB/s. As in Fig. 15, throughput increaseswith increasing number of delayed SACKs. However,this pattern does not last long since very high delayedSACK factors cannot be reached. This is because a datapacket loss yields new SACK blocks, which requiresto be transmitted back to the source immediately. Fordelayed SACK factor of 15, throughput increases upto 21.37 KB/s which corresponds to 10 times increasein the throughput performance compared to the casewithout delayed SACK, i.e., d = 1 in Fig. 15.
V. CONCLUSIONS
The inadequacy of the current TCP protocols in Inter-planetary Backbone Network has already been known andthe need for new transport protocol has been pointed out in[1]. In order to address this need, a new reliable transportprotocol, TCP-Planet, is developed in this paper. The objectiveof TCP-Planet is to address the challenges posed by theInterPlaNetary Internet for reliable data delivery and achievehigh throughput performance. TCP-Planet deploys a rate-basedadditive-increase multiplicative-decrease (AIMD) congestioncontrol scheme. It runs on top of Internet Protocol (IP) layerand does not require any specific modification to the lowerlayers in the current TCP/IP suite. Performance evaluation viasimulation experiments revealed that TCP-Planet significantlyimproves the throughput performance and addresses the chal-lenges posed by deep space communication networks.
TCP-Planet replaces the inefficient slow start algorithmswith a novel Initial State algorithm, which captures linkresources in a very fast and controlled manner. Simulationexperiments showed that TCP-Planet can reach high initialdata rates very quickly. In order to address the challengesdue to extremely high propagation delay, TCP-Planet deploysan end-to-end rate-based additive-increase multiplicative-decrease (AIMD) congestion control, whose AIMD parametersare tuned to help avoid throughput degradation. A new conges-tion control mechanism, which decouples congestion decisionfrom single packet loss events, is developed to minimizethe erroneous congestion decisions due to high link errors.Consequently, TCP-Planet improves throughput with a factormore than 103 compared to the current TCP protocols. In order
13
to reduce the effects of blackout conditions on the throughputperformance, TCP-Planet incorporates Blackout State behaviorinto the protocol operation. By this way, it achieves up to14% performance improvement in blackout conditions. Thebandwidth asymmetry problem is addressed by the adoptionof delayed SACK options. As a result, TCP-Planet is a reliabletransport protocol equipped with diverse set of algorithmsand functionalities, which can address the requirements of theInterPlaNetary Internet.
APPENDIX
The time-dependency of the transmission rate, R(t), isshown in Fig. 16. The rate-based generic AIMD scheme isassumed to increase the rate, R, additively with α at eachRTT , i.e., R = R + α. It throttles the transmission rate,R, multiplicatively by ξ if the congestion is detected, i.e.,R = ξ ·R.
�����������������������������������������������������������������������������������������������������������������������
�����������������������������������������������������������������������������������������������������������������������
N i−10 1 2 . . .
Ri.ξ
R i
LCi
α
Xi
R i+1D i
tσ σ σ σ. . .
R(t)
Fig. 16. Data rate change of rate-base generic AIMD congestion control.
Let X(t) be the total number of packets transmitted in [0, t),which can be calculated by
X(t) =
∫ t
0
R(τ)dτ (15)
For T (t) = X(t)/t being the throughput achieved in [0, t),the steady-state throughput achieved by the rate-based genericAIMD scheme is given by
T = limt→∞
1
t
∫ t
0
R(τ)dτ (16)
Let Xi be the number of packets transmitted in the ith
loss cycle, LCi, which starts and ends with rate halving dueto congestion decision. If the duration of LCi is Di, thenthe throughput achieved in LCi is given by Ti = Xi/Di.Assuming the evolution of the transmission rate Ri to beMarkov Regenerative Process with rewards Xi [19], then thesteady-state throughput can be calculated by
T = E[X]/E[D] , (17)
where E[X] and E[D] are the means of Xi and Di, respec-tively. The transmission rate change during LCi, i.e., the valueof the transmission rate at kth RTT of the LCi, is given by
Ri,k = Ri · ξ + k · α (18)
Given that Ni is the total number of RTT s in LCi, i.e., therate is throttled in (Ni − 1)th RTT, then the transmission rate
at the end of the LCi is expressed by Ri+1 = Ri · ξ+Ni ·α.Hence, the expectation of the i.i.d random variable R denotingthe transmission rate, i.e., E[R], can be calculated as
E[R] =α
1− ξ ·E[N ] , (19)
If LCi lasts for Di = Ni · σ, where σ = RTT , then the totalnumber of packets transmitted during LCi can be calculatedby
Xi =
∫ Di
0
Ri(t) · dt (20)
For rate-based AIMD scheme, whose rate change is performedwith RTT granularity, this can be calculated by replacing theintegration with the discrete summation and substituting (18)into (21) as follows
Xi =
Ni−1∑
k=0
Ri,k · σ
=
Ni−1∑
k=0
(Ri · ξ + k · α) · σ
=Ni2
[2 · ξ ·Ri + α · (Ni − 1)
]· σ (21)
Thus for mutually independent random variables of N and R,the mean of X can be calculated by taking expectation of bothsides of (21) and substituting (19) as follows
E[X] =E[N ]
2·[(1 + ξ
1− ξ)· E[N ]− 1
]· α · σ (22)
On the other hand, the total number of packets transmitted inloss cycle i can also be calculated by ni+Ri,Ni−1 ·σ, where niand Ri,Ni−1 ·σ are the number of packets transmitted until thedropped packet and in the last RTT , respectively. Therefore,E[X] can also be calculated by
E[X] = E[n] + E[R] · σ , (23)
where the expectation of the random variable n is given by
E[n] =∑
k
kP [ni = k]
=∞∑
k=0
k(1− p)k−1p =1
p, (24)
where p is the packet loss probability, if loss-based congestiondetection is used by the generic AIMD rate-based congestioncontrol algorithm. By substituting (19) and (24) into (23), andequating it to (22), we solve for E[N ] and obtain it as follows
E[N ] =3− ξ
2 · (1 + ξ)
[1 +
√1 +
8 · (1− ξ2)
α · σ · p · (3− ξ)2
](25)
Thus, it follows from (17), (22) and (25) that the steady-state throughput of the rate-based generic AIMD congestioncontrol scheme as a function of rate-increase and decrease
14
paratemeters, i.e., ξ and α, and round-trip time, σ, and thepacket loss probability p, can be expressed as follows
T (α, ξ, σ, p) =
α ·[
1 + ξ +
√(3− ξ)2 +
8 · (1− ξ2)
α · σ · p
]
4 · (1− ξ) (26)
ACKNOWLEDGMENT
This paper is dedicated to the memory of 7 astronauts onthe Columbia space shuttle. One of their missions was toinvestigate InterPlaNetary Internet and to test a mobile Internetprotocol in space.
REFERENCES
[1] O. B. Akan, J. Fang, I. F. Akyildiz, “Performance of TCP Protocols inDeep Space Communication Networks,” IEEE Commun. Lett., Vol. 6, No.11, pp. 478-480, November 2002.
[2] I. F. Akyildiz, G. Morabito, S. Palazzo, “TCP-Peach: A New CongestionControl Scheme for Satellite IP Networks,” IEEE/ACM Trans. Network-ing, Vol. 9, No. 3, pp. 307-321, June 2001.
[3] I. F. Akyildiz, X. Zhang, J. Fang, “TCP-Peach+: Enhancement of TCP-Peach for Satellite IP Networks,” IEEE Commun. Lett., Vol. 6, No. 7, pp.303-305, July 2002.
[4] H. Balakrishnan, V. N. Padmanabhan, R. H. Katz, “The Effects ofAsymmetry on TCP Performance,” Proc. ACM MOBICOM 1997, pp.77-89, Hungary, September 1997.
[5] H. Balakrishnan, V. N. Padmanabhan, S. Seshan, R. H. Katz, “A Com-parison of Mechanisms for Improving TCP Performance over WirelessLinks”, IEEE/ACM Trans. Networking, Vol. 5, No. 6, pp. 756-769,December 1997.
[6] K. Bhasin, J. Hayden, J. R. Agre, L. P. Clare, T. Y. Yan, “AdvancedCommunication and Networking Technologies for Mars Exploration,”19th Annual AIAA International Communications Satellite Systems Con-ference, Toulouse, France, April 2001.
[7] K. Bhasin, J. Hayden, “Space Internet Architectures and Technologiesfor NASA Enterprises,” Proc. IEEE Aerospace 2001, Vol. 2, pp. 931-941, 2001.
[8] L. S. Brakmo, S. O Malley, L. L. Peterson, “TCP Vegas: New Techniquesfor Congestion Detection and Avoidance,” Proc. ACM SIGCOMM 1994,pp. 24-35, October 1994.
[9] C. Casetti, M. Gerla, S. Mascolo, M. Y. Sanadidi, R. Wang, “TCP-Westwood: Bandwidth Estimation for Enhanced Transport over WirelessLinks,” Proc. ACM MOBICOM 2001, pp. 287-297, Rome, July 2001.
[10] Consultative Committee for Space Data Systems, “Space Communica-tions Protocol Specification-Transport Protocol (SCPS-TP)”, Recommen-dation for Space Data Systems Standards, CCSDS 714.0-B-1., Blue Book.Issue 1, Washington, D.C.: CCSDS, May 1999.
[11] R. C. Durst, G. J. Miller, E. J. Travis, “TCP Extensions for SpaceCommunications,” ACM/Kluwer Wireless Networks, Vol. 3, No. 5, pp.389-403, October 1997.
[12] R. C. Durst, P. D. Feighery, K. L. Scott, “Why not usethe Standard Internet Suite for the Interplanetary Internet?,”http://www.ipnsig.org/techinfo.htm.
[13] S. Floyd, T. Henderson, “The NewReno Modification to TCP’s FastRecovery Algorithm,” RFC 2585, April 1999.
[14] T. Goff, J. Moronski, D. S. Phatak, V. Gupta, “Freeze-TCP: A True End-to-End TCP Enhancement Mechanism for Mobile Environments,” Proc.INFOCOM 2000, Vol. 3 , pp. 1537-1545, Israel, 2000.
[15] T. R. Henderson, R. H. Katz, “Transport Protocols for Internet-Compatible Satellite Networks,” IEEE J. Select. Areas Commun., Vol.17, No. 2, pp. 326-344, February 1999.
[16] V. Jacobson, “Congestion Avoidance and Control,” Proc. ACM SIG-COMM 1988, pp. 314-329, Stanford, August 1988.
[17] V. Jacobson, “Berkeley TCP Evolution from 4.3-Tahoe to 4.3-Reno,”Proc. British Columbia Internet Engineering Task Force, July 1990.
[18] T. V. Lakshman, U. Madhow, “The Performance of TCP/IP for Networkswith High Bandwidth-Delay Products and Random Loss,” IEEE/ACMTrans. Networking, Vol. 5, No. 3, pp. 336-350, June 1997.
[19] D. Logothetis, K. S. Trivedi, A. Puliafito, “Markov Regenerative Mod-els”, Proc. Int. Computer Performance and Dependability Symp., pp. 134-143, Erlangen, Germany 1995.
[20] M. Mathis, J. Mahdavi, S. Floyd, A. Romanov, “TCP Selective Ac-knowledgement Options,” RFC 2018, 1996.
[21] M. Mathis, J. Mahdavi, “Forward Acknowledgement: Refining TCPCongestion Control,” Proc. ACM SIGCOMM 1996 , pp. 281-292, Aug.1996.
[22] J. Padhye, V. Firoio, D. Towsley, J. Kurose, “Modeling TCP RenoPerformance: A Simple Model and Its Empirical Validation”, IEEE/ACMTrans. Networking, Vol. 8, No. 2, pp. 133-145, April 2000.
[23] P. Sinha, N. Venkitaraman, R. Sivakumar, V. Bharghavan, “WTCP: AReliable Transport Protocol For Wireless Wide-Area Networks,” Proc.ACM MOBICOM 1999, pp. 231-241, Seattle, Washington, August 1999.
[24] D. T. Tran, F. J. Lawas-Grodek, R. P. Dimond, W. D. Ivancic, “SCPS-TP, TCP and Rate-Based Protocol Evaluation for High-Delay, Error-ProneLinks,” SpaceOps 2002, Houston, TX, October 2002.
[25] E. Travis, “The Interplanetary Internet: Architecture and Key TechnicalConcepts,” Internet Global Summit, INET 2001, June 5, 2001.
